Original: Mechanically Proving Guarantees of Generalized Heuristics: First Results and Ongoing Work
Revised: Mechanically Proving Guarantees of Generalized Heuristics: First Results and Ongoing Work

Original: Submission #

Original: Abstract
Revised: Abstract

Original: The goal of generalized planning is to ﬁnd a solution that works for all tasks of a speciﬁc planning domain.
Revised: The goal of generalized planning is to ﬁnd a solution that works for all tasks of a speciﬁc planning domain.

Original: Ideally, this solution is also efﬁcient (i.e., polynomial) in all tasks.
Revised: Ideally, this solution is also efﬁcient (i.e., polynomial) in all tasks.

Original: One possible approach is to learn such a solution from training examples and then prove that this generalizes for any given task.
Revised: One possible approach is to learn such a solution from training examples and then prove that this generalizes for any given task.

Original: However, such proofs are usually pen-and-paper proofs written by a human.
Revised: However, such proofs are usually pen-and-paper proofs written by a human.

Original: In our paper, we aim at automat- ing these proofs so we can use a theorem prover to show that a solution generalizes for any task.
Revised: In our paper, we aim at automat- ing these proofs so we can use a theorem prover to show that a solution generalizes for any task.

Original: Furthermore, we want to prove that this generalization works while still preserving efﬁciency.
Revised: Furthermore, we want to prove that this generalization works while still preserving efﬁciency.

Original: Our focus is on generalized potential heuristics en-
Revised: Our focus is on generalized potential heuristics en-

Original: coding tiered measures of progress, which can be proven to lead to a ﬁnd in a polynomial number of steps in all tasks of a domain.
Revised: coding tiered measures of progress, which can be proven to lead to a ﬁnd in a polynomial number of steps in all tasks of a domain.

Original: We show our ongoing work in this direction using the interactive theorem prover Isabelle/HOL.
Revised: We show our ongoing work in this direction using the interactive theorem prover Isabelle/HOL.

Original: We illustrate the key aspects of our implementation using the Miconic domain and then discuss possible obstacles and challenges to fully automating this pipeline.
Revised: We illustrate the key aspects of our implementation using the Miconic domain and then discuss possible obstacles and challenges to fully automating this pipeline.

Original: Introduction
Revised: Introduction

Original: Generalized planning is the problem of ﬁnding a solution that solves all tasks in a planning domain.
Revised: Generalized planning is the problem of ﬁnding a solution that solves all tasks in a planning domain.

Original: Due to the PSPACE-completeness of classical STRIPS planning the performance of such solutions is usually unpredictable.
Revised: Due to the PSPACE-completeness of classical STRIPS planning the performance of such solutions is usually unpredictable.

Original: However, for some domains polynomial solvers exist and can be synthesized automatically (e.g., Franc ` es et al. 2019a).
Revised: However, for some domains polynomial solvers exist and can be synthesized automatically (e.g., Franc ` es et al. 2019a).

Original: This is particularly interesting for situations where a given domain can be analyzed for some time before tasks of that domain have to be solved but time for solving the tasks is limited.
Revised: This is particularly interesting for situations where a given domain can be analyzed for some time before tasks of that domain have to be solved but time for solving the tasks is limited.

Original: For example, in space applications, domains can be analyzed on the ground before a mission, while calling a planner with potentially exponential running time during a mission is not feasible.
Revised: For example, in space applications, domains can be analyzed on the ground before a mission, while calling a planner with potentially exponential running time during a mission is not feasible.

Original: Most methods to synthesize polynomial solvers are based on a supervised learning approach (Yoon, Fern, and Givan 2006; Arfaee, Zilles, and Holte 2011; Franc`es et al. 2019a; Shen, Trevizan, and Thi´ebaux 2020), where the solver is learned from example tasks in the domain.
Revised: Most methods to synthesize polynomial solvers are based on a supervised learning approach (Yoon, Fern, and Givan 2006; Arfaee, Zilles, and Holte 2011; Franc`es et al. 2019a; Shen, Trevizan, and Thi´ebaux 2020), where the solver is learned from example tasks in the domain.

Original: The performance guarantee then relies on the fact that the learned solver generalizes to the whole domain.
Revised: The performance guarantee then relies on the fact that the learned solver generalizes to the whole domain.

Original: So far, the proofs for this generalization have been manual penand-paper proofs.
Revised: So far, the proofs for this generalization have been manual penand-paper proofs.

Original: This has two problems.
Revised: This has two problems.

Original: Firstly, the manual proof can be cumbersome and detailed, especially given that it might depend on all the action schemata in the given domain.
Revised: Firstly, the manual proof can be cumbersome and detailed 1 , especially given that it might depend on all the action schemata in the given domain.

Original: Secondly, due to the cumbersomeness of these manual proofs, they are error-prone, which might not sufﬁce for resource-restrained applications, especially when such applications are safety-critical.
Revised: Secondly, due to the cumbersomeness of these manual proofs, they are error-prone, which might not sufﬁce for resource-restrained applications, especially when such applications are safety-critical.

Original: In this paper, we work towards a system where such proofs are machine-checked, as well as largely automated.
Revised: In this paper, we work towards a system where such proofs are machine-checked, as well as largely automated.

Original: Towards that end, we employ an interactive theorem prover.
Revised: Towards that end, we employ an interactive theorem prover.

Original: Interactive theorem provers involve a human in the process of mechanically proving a statement.
Revised: Interactive theorem provers involve a human in the process of mechanically proving a statement.

Original: The human provides high-level proof steps and the theorem prover tries to ﬁll in the missing steps automatically.
Revised: The human provides high-level proof steps and the theorem prover tries to ﬁll in the missing steps automatically.

Original: This ability to automate cumbersome proof steps and to check the correctness of the whole proof made interactive provers an obvious choice for many applications, where proofs are cumbersome and errorprone, and especially when the underlying proof obligation is undecidable.
Revised: This ability to automate cumbersome proof steps and to check the correctness of the whole proof made interactive provers an obvious choice for many applications, where proofs are cumbersome and errorprone, and especially when the underlying proof obligation is undecidable.

Original: A notable example is program veriﬁcation, where interactive theorem provers are the most successful method to verify large scale pieces of software, e.g. an operating system kernel (Klein et al. 2009), a veriﬁed compiler for C (Leroy 2009), and an LTL model checker (Esparza et al. 2013).
Revised: A notable example is program veriﬁcation, where interactive theorem provers are the most successful method to verify large scale pieces of software, e.g. an operating system kernel (Klein et al. 2009), a veriﬁed compiler for C (Leroy 2009), and an LTL model checker (Esparza et al. 2013).

Original: Here we present our work-in-progress on a framework to mechanize proofs of performance guarantees for generalized planning heuristics.
Revised: Here we present our work-in-progress on a framework to mechanize proofs of performance guarantees for generalized planning heuristics.

Original: In particular, we focus on generalized potential heuristics (Franc`es et al. 2019a), which are weighted sums of state features.
Revised: In particular, we focus on generalized potential heuristics (Franc`es et al. 2019a), which are weighted sums of state features.

Original: In contrast to potential heuristics in classical planning (Pommerening et al. 2014), features are deﬁned with a description logic and can be evaluated in all tasks of a domain.
Revised: In contrast to potential heuristics in classical planning (Pommerening et al. 2014), features are deﬁned with a description logic and can be evaluated in all tasks of a domain.

Original: Franc ` es et al.
Revised: Franc`es et al.

Original: prove that several learned generalized potential heuristics (for different domains) lead to a backtrack-free search in any possible task of the domain where the heuristic value decreases by at least 1 in every step.
Revised: prove that several learned generalized potential heuristics (for different domains) lead to a backtrack-free search in any possible task of the domain where the heuristic value decreases by at least 1 in every step.

Original: Together with a guarantee on the maximal and minimal heuristic value, this ensures a polynomial search effort.
Revised: Together with a guarantee on the maximal and minimal heuristic value, this ensures a polynomial search effort.

Original: However, all these proofs were done manually by the authors.
Revised: However, all these proofs were done manually by the authors.

Original: This is clearly not an ideal scenario, as the ultimate goal of generalized planning is to come up with such heuristics and their performance guarantees without input or help from a user.
Revised: This is clearly not an ideal scenario, as the ultimate goal of generalized planning is to come up with such heuristics and their performance guarantees without input or help from a user.

Original: The framework we work on uses the interactive theorem prover Isabelle/HOL (Nipkow, Wenzel, and Paulson 2002) to formally verify these manual proofs.
Revised: The framework we work on uses the interactive theorem prover Isabelle/HOL (Nipkow, Wenzel, and Paulson 2002) to formally verify these manual proofs.

Original: We develop a framework for interactive reasoning about annotated PDDL domains.
Revised: We develop a framework for interactive reasoning about annotated PDDL domains.

Original: Such annotations include (i) domain assumptions, i.e. properties that should hold for all instances of the domain, (ii) domain invariants, which are properties that follow from the action descriptions and domain assumptions for every reachable state in every instance of the domain, and (iii) generalized heuristics, which we prove to be descending.
Revised: Such annotations include (i) domain assumptions, i.e. properties that should hold for all instances of the domain, (ii) domain invariants, which are properties that follow from the action descriptions and domain assumptions for every reachable state in every instance of the domain, and (iii) generalized heuristics, which we prove to be descending.

Original: Given such an annotated domain, this framework is capable of parsing the domain, automatically proving many properties about it, and leaving only the core proof tasks for the user to be proven interactively.
Revised: Given such an annotated domain, this framework is capable of parsing the domain, automatically proving many properties about it, and leaving only the core proof tasks for the user to be proven interactively.

Original: Not all parts of the framework that could be automated are automated yet and it is currently limited to generalized potential heuristics that form tiered measures of progress (Parmar 2002).
Revised: Not all parts of the framework that could be automated are automated yet and it is currently limited to generalized potential heuristics that form tiered measures of progress (Parmar 2002).

Original: As a proof of concept, we interactively completed the relevant proofs for the domain Miconic and were able to prove that the generalized heuristic computed for it using the method of Franc`es et al.
Revised: As a proof of concept, we interactively completed the relevant proofs for the domain Miconic and were able to prove that the generalized heuristic computed for it using the method of Franc`es et al.

Original: indeed has the reported performance guarantee.
Revised: indeed has the reported performance guarantee.

Original: Together with a method to create hypothesis heuristics such as the one by Franc`es et al.
Revised: Together with a method to create hypothesis heuristics such as the one by Franc ` es et al.

Original: , our framework could be developed into an integrated tool to ﬁnd solutions to a generalized planning task that come with a formally veriﬁed performance guarantee.
Revised: , our framework could be developed into an integrated tool to ﬁnd solutions to a generalized planning task that come with a formally veriﬁed performance guarantee.

Original: Running Example: Miconic
Revised: Running Example: Miconic

Original: Throughout the paper, we use the Miconic domain (Koehler and Schuster 2000) as a running example.
Revised: Throughout the paper, we use the Miconic domain (Koehler and Schuster 2000) as a running example.

Original: In this domain, passengers start at different ﬂoors of a building and each passenger has one speciﬁc destination ﬂoor.
Revised: In this domain, passengers start at different ﬂoors of a building and each passenger has one speciﬁc destination ﬂoor.

Original: The goal is to ﬁnd a plan where an elevator transports each passenger to its destination.
Revised: The goal is to ﬁnd a plan where an elevator transports each passenger to its destination.

Original: Miconic can be seen as a logistics problem where a vehicle (the elevator) needs to transport items (passengers) to their desired destination.
Revised: Miconiccan be seen as a logistics problem where a vehicle (the elevator) needs to transport items (passengers) to their desired destination.

Original: Franc ` es et al. (2019a) showed that it is possible to synthesize a compact planner for this domain.
Revised: Franc ` es et al. (2019a) showed that it is possible to synthesize a compact planner for this domain.

Original: Generalized Planning
Revised: Generalized Planning

Original: We consider STRIPS planning tasks with negation represented in PDDL (McDermott et al.
Revised: We consider STRIPS planning tasks with negation represented in PDDL (McDermott et al.

Original: Haslum et al.
Revised: Haslum et al.

Original: A PDDL planning task is encoded using a ﬁrst-order vocabulary and can compactly represent a state space.
Revised: A PDDL planning task is encoded using a ﬁrst-order vocabulary and can compactly represent a state space.

Original: The ﬁrst-order vocabulary of a task deﬁnes a domain .
Revised: The ﬁrst-order vocabulary of a task deﬁnes a domain .

Original: A domain is a triple Σ =
Revised: A domain is a tuple Σ =

Original: (cid:104)P , C , A , X(cid:105) , where P is a set of predicate symbols , C is a set of constants (i.e., nullary functions), A is a set of PDDL action schemas , and X is a set of ﬁrst-order logic formulas, called domain assumptions , which we will discuss later.
Revised: (cid:104)P , C , A , X(cid:105) , where P is a set of predicate symbols , C is a set of constants (i.e., nullary functions), A is a set of PDDL action schemas , and X is a set of ﬁrst-order logic formulas, called domain assumptions , which we will discuss later.

Original: A lifted atom is a ﬁrst-order atom P ( x 1 , . . .
Revised: A lifted atom is a ﬁrst-order atom P ( x 1 , . . .

Original: , x n ) where P ∈ P and all x i are either variables or objects from C .
Revised: , x n ) where P ∈ P and all x i are either variables or objects from C .

Original: A lifted literal is either a lifted atom or its negation.
Revised: A lifted literal is either a lifted atom or its negation.

Original: A PDDL action schema a ∈ A is represented with a precondition pre ( a ) and a set of add effects add ( a ) , and a set of delete effects del ( a ) , where pre ( a ) is a set of lifted literals and both add ( a ) and del ( a ) are sets of lifted atoms.
Revised: A PDDL action schema a ∈ A is represented with a precondition pre ( a ) and a set of add effects add ( a ) , and a set of delete effects del ( a ) , where pre ( a ) is a set of lifted literals and both add ( a ) and del ( a ) are sets of lifted atoms.

Original: A planning task Π in a domain Σ is a tuple (cid:104)O , I , G(cid:105) , where O is a set of objects , I is the initial state , and G is the goal condition .
Revised: A planning task Π in a domain Σ is a tuple (cid:104)O , I , G(cid:105) , where O is a set of objects , I is the initial state , and G is the goal condition .

Original: A predicate symbol P ∈ P applied to constants in C ∪ O is a (ground) atom and a subset of atoms is a state with the interpretation that all atoms in the state are true, while all others are false.
Revised: A predicate symbol P ∈ P applied to constants in C ∪ O is a (ground) atom and a subset of atoms is a state with the interpretation that all atoms in the state are true, while all others are false.

Original: The initial state I is a state, while G is a set of atoms with the interpretation that our aim is to make all atoms in G true.
Revised: The initial state I is a state, while G is a set of atoms with the interpretation that our aim is to make all atoms in G true.

Original: Any state s where G ⊆ s is a goal state .
Revised: Any state s where G ⊆ s is a goal state .

Original: The set of domain assumptions X contains ﬁrstorder formulas over I and G that restrict which instances we consider part of the domain.
Revised: The set of domain assumptions X contains ﬁrstorder formulas over I and G that restrict which instances we consider part of the domain.

Original: Action schemas a ∈ A can be grounded by consistently replacing the variables in pre ( a ) , add ( a ) , and del ( a ) with constants from C
Revised: Action schemas a ∈ A can be grounded by consistently replacing the variables in pre ( a ) , add ( a ) , and del ( a ) with constants from C

Original: ∪ O .
Revised: ∪ O .

Original: If every atom in the precondition of a ground action is true in a state, we say the action is applicable .
Revised: If every atom in the precondition of a ground action is true in a state, we say the action is applicable .

Original: If an action a is applicable in a state s then applying it leads to the successor state s [ a ] =
Revised: If an action a is applicable in a state s then applying it leads to the successor state s [ a ] =

Original: ( s \ del ( a )) ∪ add ( a ) .
Revised: ( s \ del ( a )) ∪ add ( a ) .

Original: The set of successor states of a state s is succ ( s ) =
Revised: The set of successor states of a state s is succ ( s ) =

Original: { s [ a ] | a is applicable in s } .
Revised: { s [ a ] | a is applicable in s } .

Original: Example 1 In the Miconic domain, the set P has the following predicates: origin ( p, f ) , indicating that passenger p starts at ﬂoor f ; destin ( p, f ) , indicating that passenger p ’s destination is ﬂoor f ; boarded ( p ) , indicating that passenger p has boarded into the elevator; served ( p ) , indicating that passenger p has reached their destination; lift-at ( f ) indicating that the elevator is in ﬂoor f ; ﬂoor ( f ) and passenger ( p ) indicating the types of f and p ; and above, indicating the order of ﬂoors.
Revised: Example 1 In the Miconic domain, the set P has the following predicates: origin ( p, f ) , indicating that passenger p starts at ﬂoor f ; destin ( p, f ) , indicating that passenger p ’s destination is ﬂoor f ; boarded ( p ) , indicating that passenger p has boarded into the elevator; served ( p ) , indicating that passenger p has reached their destination; lift-at ( f ) indicating that the elevator is in ﬂoor f ; ﬂoor ( f ) and passenger ( p ) indicating the types of f and p ; and above ( f 1 , f 2 ) , indicating the order of ﬂoors.

Original: The set C is empty for this domain and all constants are deﬁned by the set of objects O of each instance.
Revised: The set C is empty for this domain and all constants are deﬁned by the set of objects O of each instance.

Original: There are four action schemas in the domain: move the elevator up or down ; letting a passenger board at their origin or letting them depart at their destination.
Revised: There are four action schemas in the domain: move the elevator up or down ; letting a passenger board at their origin or letting them depart at their destination.

Revised: Moving the elevator from f 1 to f 2 requires and then deletes lift-at ( f 1 ) and adds lift-at ( f 2 ) .

Revised: A passenger can board an elevator on its origin ﬂoor which adds boarded ( p ) (due to a modeling bug in the IPC domain there is this can be done even if passenger is already boarded).

Revised: Similarly, a boarded passenger can depart only at their destination, which deletes boarded ( p ) and adds served ( p ) .

Revised: Additional conditions ensure that the action parameters have the correct types using the predicates ﬂoor ( f ) and passenger ( p ) .

Original: The domain assumptions X contain formulas restricting the instances we consider as part of the domain.
Revised: The domain assumptions X contain formulas restricting the instances we consider as part of the domain.

Original: For example, we use a domain assumption for the fact that the goal consists of serving passengers:
Revised: For example, we use a domain assumption for the fact that the goal consists of serving passengers:

Original: [Equation]
Revised: [Equation]

Original: Other examples would be the assumptions that initially the lift is at exactly one ﬂoor, and that every person has exactly one origin and one destination ﬂoor.
Revised: Other examples would be the assumptions that initially the lift is at exactly one ﬂoor, and that every person has exactly one origin and one destination ﬂoor.

Original: Note that these assumptions are consistent with the original Miconic instances (Koehler and Schuster 2000).
Revised: Note that these assumptions are consistent with the original Miconic instances (Koehler and Schuster 2000).

Original: Generalized planning is the problem of ﬁnding solutions that work for any given task of a ﬁxed domain (Jim´enez,
Revised: Generalized planning is the problem of ﬁnding solutions that work for any given task of a ﬁxed domain (Jim´enez,

Original: Segovia-Aguas, and Jonsson 2019).
Revised: Segovia-Aguas, and Jonsson 2019).

Original: In other words, given a ﬁxed domain Σ , we want to solve any possible task Π of Σ .
Revised: In other words, given a ﬁxed domain Σ , we want to solve any possible task Π of Σ .

Original: Generalized Potential Heuristics

Original: A heuristic is a function h mapping states to R 0 .
Revised: A heuristic is a function h mapping states to R 0 .

Original: A generalized heuristic is a function deﬁned over all states of all possible tasks of a given domain.
Revised: A generalized heuristic is a function deﬁned over all states of all possible tasks of a given domain.

Original: We use some terminology by Seipp et al.
Revised: We use some terminology by Seipp et al.

Original: (2016) to characterize heuristics: a state is alive if it is not a goal state, reachable from the initial state, and a goal state is reachable from it.
Revised: (2016) to characterize heuristics: a state is alive if it is not a goal state, reachable from the initial state, and a goal state is reachable from it.

Original: A heuristic h is descending on a state s if s has at least one successor s (cid:48)
Revised: A heuristic h is descending on a state s if s has at least one successor s (cid:48)

Original: where h ( s (cid:48) )
Revised: where h ( s (cid:48) )

Original: ≤ h ( s ) − 1 , and it is dead-end avoiding on a state s if for every unsolvable state in s (
Revised: ≤ h ( s ) − 1 , and it is dead-end avoiding on a state s if for every unsolvable state in s (

Original: cid:48) ∈ succ ( s ) h ( s ) <
Revised: cid:48) ∈ succ ( s ) h ( s ) <

Original: h ( s (cid:48) ) .
Revised: h ( s (cid:48) ) .

Original: A heuristic is descending and dead-end avoiding (DDA) if it is descending and dead-end avoiding on every alive state.
Revised: A heuristic is descending and dead-end avoiding (DDA) if it is descending and dead-end avoiding on every alive state.

Original: Heuristics with this property guide standard greedy algorithms directly to a goal and are desirable in satisﬁcing planning (Helmert et al. 2022).
Revised: Heuristics with this property guide standard greedy algorithms directly to a goal and are desirable in satisﬁcing planning (Helmert et al. 2022).

Original: Franc`es et al.
Revised: Franc`es et al.

Original: (2019a) introduce the concept of generalized potential heuristics , which are weighted sums over features mapping states to integers.
Revised: (2019a) introduce the concept of generalized potential heuristics , which are weighted sums over features mapping states to integers.

Revised: We limit both weight functions and features to natural numbers.

Original: Deﬁnition 1 (Generalized Potential Heuristics) Let S be a set of states, F be a set of features f : S → Z , and w : F → R be a weight function.
Revised: Deﬁnition 1 (Generalized Potential Heuristics) Let S be a set of states, F be a set of features f : S → N , and w : F → N be a weight function.

Original: The value of the generalized potential heuristic with features F and weights w on a state s ∈ S is
Revised: The value of the generalized potential heuristic with features F and weights w on a state s ∈ S is

Original: [Equation]
Revised: [Equation]

Original: In our work, we are interested exclusively in cardinality features over description logic (DL) concepts and roles .
Revised: In our work, we are interested exclusively in cardinality features over description logic (DL) concepts and roles .

Original: We use the SOI language with equality role-value-maps (Baader et al. 2003).
Revised: We use the SOI language with equality role-value-maps (Baader et al. 2003).

Original: This language can be deﬁned with the following production rules:
Revised: This language can be deﬁned with the following production rules:

Original: [Equation]
Revised: [Equation]

Original: where A C is a set of named concepts , forming the basis of the inductive deﬁnition, and a 1 , . .
Revised: where A C is a set of named concepts , forming the basis of the inductive deﬁnition, and a 1 , . .

Original: . , a n are nominals .
Revised: . , a n are nominals .

Original: Similarly, roles are deﬁned as follows
Revised: Similarly, roles are deﬁned as follows

Original: [Equation]
Revised: [Equation]

Original: where A R is a set of named roles .
Revised: where A R is a set of named roles .

Original: Due to space limitation, we point the reader to Franc`es et al. (2019a) and Baader et al.
Revised: Due to space limitation, we point the reader to Franc`es et al. (2019a) and Baader et al.

Original: (2003) for detailed explanations on the semantics of each constructor above.
Revised: (2003) for detailed explanations on the semantics of each constructor above.

Revised: Intuitively, in a state s a named concept A C like boarded evaluates to the set of objects o , where boarded ( o ) ∈ s .

Revised: The concepts (cid:62) and ⊥ , { a 1 , . . . , a n } evaluate to the set of all, no, or the explicitly listed objects.

Revised: The concepts ¬ C , C 1 (cid:116) C 2 and C 1 (cid:117) C 2 have their intuitive interpretation using set complement, union and intersection.

Revised: Roles evaluate to relations over objects, for example named roles A R like origin evaluate to the set of tuples ( p, f ) where origin ( p, f ) ∈ s .

Revised: The roles R − 1 , R 1 ◦ R 2 and R + evaluate to the inverse relation, relational composition and transitive closure of the recursive evaluations.

Original: The  value of a feature| f  | is the cardinality of the concept/role f evaluated in the respective state.
Revised: The more complex concept ∃ R.C evaluates to the set of all objects x such that there is an object y such that ( x, y ) is in the evaluation of R and y is in the evaluation of f C . The concept ∀ R.C is analogously deﬁned and the concept R 1 = R 2 evaluates to all objects x such that for all y , the tuple ( x, y ) is either contained in both roles or in none of them. The value of a feature f = | c | is the cardinality of the concept c evaluated in the respective state.

Original: Example 

Revised: Example

Original: The Miconic domain uses named concepts
Revised: The Miconic domain uses named concepts

Original: A C = { served, boarded, lifted-at } and named roles A R = { origin, destin } .
Revised: A C = { served, boarded, lift-at } and named roles A R = { origin, destin } .

Original: We also consider the following concepts: not-boarded-needs-lift :
Revised: We also consider the following concepts: not-boarded-needs-lift :=

Original: = passenger (cid:117) ¬ served (cid:117)
Revised: passenger (cid:117) ¬ served (cid:117)

Original: ¬ boarded (cid:117) ( ∀ origin .
Revised: ¬ boarded (cid:117) ( ∀ origin .

Original: ¬ lift-at ) not-boarded-has-lift :=
Revised: ¬ lift-at ) not-boarded-has-lift :=

Original: passenger (cid:117) ¬ served (cid:117)
Revised: passenger (cid:117) ¬ served (cid:117)

Original: ¬ boarded (cid:117)
Revised: ¬ boarded (cid:117)

Original: ( ∃ origin .
Revised: ( ∃ origin .

Original: lift-at ) boarded-wrong-place := passenger (cid:117)
Revised: lift-at ) boarded-wrong-place := passenger (cid:117)

Original: ¬ served (cid:117) boarded (cid:117) ( ∀ destin .
Revised: ¬ served (cid:117) boarded (cid:117) ( ∀ destin .

Original: ¬ lift-at ) boarded-right-place := passenger (cid:117) ¬ served (cid:117) boarded (cid:117)
Revised: ¬ lift-at ) boarded-right-place := passenger (cid:117) ¬ served (cid:117) boarded (cid:117)

Original: ( ∃ destin .
Revised: ( ∃ destin .

Original: lift-at ) passenger-served := passenger (cid:117) served .
Revised: lift-at ) passenger-served := passenger (cid:117) served .

Original: We can encode the following generalized potential heuristic h using the concepts above: h =5 · | not-boarded-needs-lift | + 4 · | not-boarded-has-lift | + 3 · | boarded-wrong-place | + 2 · | boarded-right-place | + 1 · | passenger-served | .
Revised: We can encode the following generalized potential heuristic h using the concepts above: [Equation] needs [Equation]

Original: The generalized potential heuristic above encodes a tiered measure of progress (Parmar 2002).
Revised: lift [Equation] not-boarded-has-lift | [Equation]

Revised: boarded-wrong-place | +

Revised: [Equation]

Revised: · | boarded-right-place | + 1 · | passenger-served | .

Revised: The generalized potential heuristic above encodes a tiered measure of progress (Parmar 2002).

Original: In words, the different concepts used in the heuristic describe different tiers, and an object of the task can only be part of one concept per state (i.e., the intersection of two concepts is empty).
Revised: In words, the different concepts used in the heuristic describe different tiers, and an object of the task can only be part of one concept per state (i.e., the intersection of two concepts is empty).

Original: The idea is that these concepts are ordered – from best to worst – with respect to the goal condition.
Revised: The idea is that these concepts are ordered – from best to worst – with respect to the goal condition.

Original: Moving one object from one concept to a better one decreases the heuristic value.
Revised: Moving one object from one concept to a better one decreases the heuristic value.

Original: A heuristic encodes a tiered measure of progress if it is always possible to apply an action in a non-goal state to move an object from one concept to a better one.
Revised: A heuristic encodes a tiered measure of progress if it is always possible to apply an action in a non-goal state to move an object from one concept to a better one.

Original: That is the case for the heuristic h in Example 2.
Revised: That is the case for the heuristic h in Example 2.

Original: This implies that h is descending for Miconic, and  a greedy search guided by h will solve the task in polynomial time in the number of objects (Franc`es et al. 2019a).
Revised: This implies that h is descending for Miconic. Since every action moves at least one object to a better concept and the number of concepts is constant, a greedy search guided by h will only take polynomial time in the number of objects (Franc`es et al. 2019a).

Original: Currently, all proofs to show that a heuristic h is a tiered measure of progress (and thus descending) are done manually (Parmar 2002; Yoon, Fern, and Givan 2006; Franc`es et al. 2019b).
Revised: Currently, all proofs to show that a heuristic h is a tiered measure of progress (and thus descending) are done manually (Parmar 2002; Yoon, Fern, and Givan 2006; Franc`es et al. 2019b).

Original: We work towards a system to automate this process.
Revised: We work towards a system to automate this process.

Original: Approach
Revised: Approach

Original: Tiered measures of progress guide a hill-climbing search directly to the goal, so they have guaranteed polynomial performance.
Revised: Tiered measures of progress guide a hill-climbing search directly to the goal, so they have guaranteed polynomial performance.

Original: However, so far, all methods that use measures of progress either come up with them manually (Parmar 2002), or create them based on sample tasks (Yoon, Fern, and Givan 2006; Franc ` es et al. 2019a).
Revised: However, so far, all methods that use measures of [Figure] h [Figure]

Revised: Prove background theory

Revised: Prove domain theory

Revised: Find and prove invariants

Revised: Prove number of features is ﬁnite (A1)

Revised: Prove no features occurs twice in h (A2)

Revised: Prove concepts are mutually exclusive (A3)

Revised: Case distinction over which concepts are empty

Revised: Find a witness action

Revised: Prove no new object appears during transition (A4)

Revised: Prove no object moves to a worse concept (A5)

Revised: Prove (at least) one object moves to a better concept (A5)

Revised: Prove steps above imply h is descending for each case progress either come up with them manually (Parmar 2002), or create them based on sample tasks (Yoon, Fern, and Givan 2006; Franc`es et al. 2019a).

Original: In both cases, it remains to show that the progress measure is a strong measure of progress for all tasks in the domain, i.e., that it generalizes beyond the sample tasks.
Revised: In both cases, it remains to show that the progress measure is a strong measure of progress for all tasks in the domain, i.e., that it generalizes beyond the sample tasks.

Original: Our long-term goal is to have a system that can automatically generate a solver with a formally veriﬁed performance guarantees for a given domain.
Revised: Our long-term goal is to have a system that can automatically generate a solver with a formally veriﬁed performance guarantees for a given domain.

Original: Such a guarantee on the performance is particularly important for systems that have to know in advance how much computational resources are required to solve a task, for example in space applications where battery power is severely limited.
Revised: Such a guarantee on the performance is particularly important for systems that have to know in advance how much computational resources are required to solve a task, for example in space applications where battery power is severely limited.

Original: We show the ﬁrst steps toward this goal.
Revised: We show the ﬁrst steps toward this goal.

Original: The system we envision would work in two phases:
Revised: The system we envision would work in two phases:

Original: Find a hypothesis, in our case a generalized potential heuristic that is descending on some sample tasks.
Revised: Find a hypothesis, in our case a generalized potential heuristic that is descending on some sample tasks.

Original: Prove (semi-)automatically that the hypothesis generalizes to all tasks in the domain, in our case, that the heuristic is descending on all tasks in the domain.
Revised: Prove (semi-)automatically that the hypothesis generalizes to all tasks in the domain, in our case, that the heuristic is descending on all tasks in the domain.

Original: If this is not the case, generate more samples and start from phaseagain.
Revised: If this is not the case, generate more samples and start from phase again.

Original: Phase 1 is already handled by Franc`es et al. (2019a) whose method is guaranteed to ﬁnd a heuristic that is descending on all sample tasks if such a heuristic exists.
Revised: Phase 1 is already handled by Franc`es et al. (2019a) whose method is guaranteed to ﬁnd a heuristic that is descending on all sample tasks if such a heuristic exists.

Original: We work on Phase 2 here.
Revised: We work on Phase 2 here.

Original: In particular, we use automated and interactive theorem provers to show that a given generalized potential heuristic is indeed descending on all tasks of a domain.
Revised: In particular, we use automated and interactive theorem provers to show that a given generalized potential heuristic is indeed descending on all tasks of a domain.

Original: To do so, we make a case distinction and show in each case that there is a witness action – an action that is applicable in this case and only moves objects to better concepts.
Revised: To do so, we make a case distinction and show in each case that there is a witness action – an action that is applicable in this case and only moves objects to better concepts.

Original: This in turn shows that the heuristic is a tiered measure of progress and thus descending in all tasks.
Revised: This in turn shows that the heuristic is a tiered measure of progress and thus descending in all tasks.

Original: A fully automated process for this step is not possible, as some of the involved problems are undecidable in general.
Revised: A fully automated process for this step is not possible, as some of the involved problems are undecidable in general.

Original: Interactive theorem proving involves the user in steps where no complete methods exist, or where a fully automated solution would require an impractical amount of time.
Revised: Interactive theorem proving involves the user in steps where no complete methods exist, or where a fully automated solution would require an impractical amount of time.

Original: Our hope is to automate as many steps as possible so the user can focus on the core problems.
Revised: Our hope is to automate as many steps as possible so the user can focus on the core problems.

Original: Since interactive proofs are checked by Isabelle/HOL (Nipkow, Wenzel, and Paulson 2002), the ﬁnal result is a complete formally veriﬁed proof about the performance of the involved heuristic.
Revised: Since interactive proofs are checked by Isabelle/HOL (Nipkow, Wenzel, and Paulson 2002), the ﬁnal result is a complete formally veriﬁed proof about the performance of the involved heuristic.

Original: As we are reporting on work in progress, not all steps in the process are ﬁnished yet.
Revised: As we are reporting on work in progress, not all steps in the process are ﬁnished yet.

Original: In its current form, our implementation sets up a formal proof environment in the interactive theorem prover Isabelle/HOL.
Revised: In its current form, our implementation sets up a formal proof environment in the interactive theorem prover Isabelle/HOL.

Revised: This implementation proves the statements we discuss in the rest of the paper and it is available online (Abdulaziz, Pommerening, and Corr ˆ ea 2022).

Revised: Figure 1 gives an overview of the process.

Revised: It also distinguishes between stepts that are interactive, fully automated, or not yet implemented.

Original: As input, we take a PDDL description of the domain together with a description of domain assumptions and a list of invariants for the domain.
Revised: As input, we take a PDDL description of the domain together with a description of domain assumptions and a list of invariants for the domain.

Original: PDDL ﬁles only describe the set of predicates P , constants C , and action schemas A .
Revised: PDDL ﬁles only describe the set of predicates P , constants C , and action schemas A .

Original: Furthermore, we supplement it with the domain assumptions X and invariants.
Revised: Furthermore, we supplement it with the domain assumptions X and invariants.

Original: Similar to the domain assumptions, invariants are also ﬁrst-order logic formulas.
Revised: Similar to the domain assumptions, invariants are also ﬁrst-order logic formulas.

Original: The idea is that if an invariant formula I holds in a given state s then it also holds in the successors of s .
Revised: The idea is that if an invariant formula I holds in a given state s then it also holds in the successors of s .

Original: In contrast to domain assumptions, invariants need to be proved as consequences of the domain description and the domain assumptions.
Revised: In contrast to domain assumptions, invariants need to be proved as consequences of the domain description and the domain assumptions.

Original: If an invariant holds for an initial state according to our assumptions X , then it will hold on any reachable state (by induction).
Revised: If an invariant holds for an initial state according to our assumptions X , then it will hold on any reachable state (by induction).

Original: Example 

Revised: Example

Original: In Miconic, we use invariants to express that predicates like passenger are static, i.e., that if p is a passenger in the initial state, p will be a passenger in all reachable states.
Revised: In Miconic, we use invariants to express that predicates like passenger are static, i.e., that if p is a passenger in the initial state, p will be a passenger in all reachable states.

Original: Another invariant expresses that served ( p ) ∈
Revised: Another invariant expresses that served ( p ) ∈

Original: s implies boarded ( p ) / ∈ s for all reachable states s .
Revised: s implies boarded ( p ) / ∈ s for all reachable states s .

Original: In total, we use ten such invariants in Miconic.
Revised: In total, we use ten such invariants in Miconic.

Original: For each invariant, we have an accompanying domain axiom claiming that the invariant holds in the initial state.
Revised: For each invariant, we have an accompanying domain axiom claiming that the invariant holds in the initial state.

Original: The complete system would have to prove that each claimed invariant is actually invariant across the application of any action.
Revised: The complete system would have to prove that each claimed invariant is actually invariant across the application of any action.

Original: Our prototype currently does not perform this step.
Revised: Our prototype currently does not perform this step.

Original: In addition to the domain and the invariants we also read in a ﬁle containing a list of concepts and a description of the heuristic (the weights of involved concepts).
Revised: In addition to the domain and the invariants we also read in a ﬁle containing a list of concepts and a description of the heuristic (the weights of involved concepts).

Original: We currently are limited to cardinality features but kept the system open to possibly extend this in the future.
Revised: We currently are limited to cardinality features but kept the system open to possibly extend this in the future.

Original: In the full system, the domain and domain axioms would have to be provided by the user, and the heuristic would be discovered in Phase 1, for example with the method by Franc`es et al. (2019a).
Revised: In the full system, the domain and domain axioms would have to be provided by the user, and the heuristic would be discovered in Phase 1, for example with the method by Franc`es et al. (2019a).

Original: Invariants could be discovered automatically but since there is an inﬁnite number of invariants in each domain ﬁnding a sufﬁciently large set of invariants likely has to involve the user.
Revised: Invariants could be discovered automatically but since there is an inﬁnite number of invariants in each domain ﬁnding a sufﬁciently large set of invariants likely has to involve the user.

Original: We hope that in the future, we can set up the proof environment in such a way that failed interactive proof attempts fail with an error that helps the user identify missing invariants.
Revised: We hope that in the future, we can set up the proof environment in such a way that failed interactive proof attempts fail with an error that helps the user identify missing invariants.

Original: In the theory that we set up automatically, the user then has to prove the following properties interactively:
Revised: In the theory that we set up automatically, the user then has to prove the following properties interactively:

Original: Given two concepts, show that they are mutually exclusive, i.e., there is no state where an object is in two of the concepts.
Revised: Given two concepts, show that they are mutually exclusive, i.e., there is no state where an object is in two of the concepts.

Original: Prove that all invariants speciﬁed in the input ﬁles are indeed invariant, i.e., if they hold before an action application, they hold after the action application.
Revised: Prove that all invariants speciﬁed in the input ﬁles are indeed invariant, i e., if they hold before an action application, they hold after the action application.

Original: Possibly split cases further.
Revised: Possibly split cases further.

Original: We automatically set up a case distinction for alive states based on the concepts used in the heuristic.
Revised: We automatically set up a case distinction for alive states based on the concepts used in the heuristic.

Original: This automatic case distinction orders the concepts of the heuristic and has one case per concept where this concept is non-empty and every earlier concept is empty.
Revised: This automatic case distinction orders the concepts of the heuristic and has one case per concept where this concept is non-empty and every earlier concept is empty.

Original: The idea is that the concepts represent a tiered measure of progress and we distinguish cases based on the ﬁrst non-empty tier in this progress measure.
Revised: The idea is that the concepts represent a tiered measure of progress and we distinguish cases based on the ﬁrst non-empty tier in this progress measure.

Original: If another case split is required, this has to be done interactively.
Revised: If another case split is required, this has to be done interactively.

Original: In each case, specify a witness action that will lead to a decreasing heuristic value in alive states of this case or show a contradiction in the case.
Revised: In each case, specify a witness action that will lead to a decreasing heuristic value in alive states of this case or show a contradiction in the case.

Original: Specifying a wit - ness action amounts to choosing an action schema and deﬁning parameters of that action.
Revised: Specifying a witness action amounts to choosing an action schema and deﬁning parameters of that action.

Original: The parameters have to be objects whose existence we can derive from the case.
Revised: The parameters have to be objects whose existence we can derive from the case.

Original: For example, if we handle a case where the concept passenger (cid:117) ¬ served is non-empty, we can derive the existence of an object p such that passenger ( p ) ∈ s and served ( p ) / ∈ s .
Revised: For example, if we handle a case where the concept passenger (cid:117) ¬ served is non-empty, we can derive the existence of an object p such that passenger ( p ) ∈ s and served ( p ) / ∈ s .

Original: This object can then be used as a parameter in the witness action.
Revised: This object can then be used as a parameter in the witness action.

Original: Showing a contradiction in a case usually involves showing that all states in this case are goal states.
Revised: Showing a contradiction in a case usually involves showing that all states in this case are goal states.

Original: For example, if the concept passenger (cid:117)¬ served is empty, we can use the domain axiom that the goal consists only of served facts for passengers to show that all goals are satisﬁed.
Revised: For example, if the concept passenger (cid:117)¬ served is empty, we can use the domain axiom that the goal consists only of served facts for passengers to show that all goals are satisﬁed.

Original: Since we make a case distinction over alive states, showing that all states in a case are goal states (and thus not alive) yields a contradiction.
Revised: Since we make a case distinction over alive states, showing that all states in a case are goal states (and thus not alive) yields a contradiction.

Original: Currently, we have interactive proofs for our Miconic use case for all of these steps except for proving the invariants.
Revised: Currently, we have interactive proofs for our Miconic use case for all of these steps except for proving the invariants.

Original: As the invariants we use are simple, we do not expect large problems proving them interactively, however, if we accept arbitrary ﬁrst-order formulas as invariants, proving them is a semi-decidable problem, so an automated method will fail in some cases where the domain does not hold.
Revised: As the invariants we use are simple, we do not expect large problems proving them interactively, however, if we accept arbitrary ﬁrst-order formulas as invariants, proving them is a semi-decidable problem, so an automated method will fail in some cases where the domain does not hold.

Original: Our framework is limited to generalized potential heuristics that encode tiered measures of progress where the concepts are mutex.
Revised: Our framework is limited to generalized potential heuristics that encode tiered measures of progress where the concepts are mutex.

Original: We view this as an interesting use case because an intuitive way of specifying a progress measure is to describe the different stages certain objects can be in (e.g., passengers ﬁrst wait for a lift, then are about to enter a lift, wait inside the lift, are about to exit the lift, and ﬁnally arrive at their destination).
Revised: We view this as an interesting use case because an intuitive way of specifying a progress measure is to describe the different stages certain objects can be in (e.g., passengers ﬁrst wait for a lift, then are about to enter a lift, wait inside the lift, are about to exit the lift, and ﬁnally arrive at their destination).

Original: The description of these stages expressed with a description logic naturally forms mutex concepts and a tiered measure of progress.
Revised: The description of these stages expressed with a description logic naturally forms mutex concepts and a tiered measure of progress.

Original: We discuss the individual steps of our framework in more detail in the following sections.
Revised: We discuss the individual steps of our framework in more detail in the following sections.

Original: Foundations for Formal Reasoning about Domains and Heuristics
Revised: Foundations for Formal Reasoning about Domains and Heuristics

Original: One of our main contributions is constructing a formal mathematical background theory to aid in the formal reasoning about PDDL domains and formulas in the DL fragment we use.
Revised: One of our main contributions is constructing a formal mathematical background theory to aid in the formal reasoning about PDDL domains and formulas in the DL fragment we use.

Original: Such a background theory has to contain a formalization of the syntax and semantics of PDDL and the DL fragment in Isabelle/HOL’s logic.
Revised: Such a background theory has to contain a formalization of the syntax and semantics of PDDL and the DL fragment in Isabelle/HOL’s logic.

Original: The syntax of PDDL and the description logic is formalized in the form of an abstract syntax tree, and the semantics are formalized by deﬁning functions and predicates (e.g. deﬁning what is a valid plan, or what is the result of action execution) operating on the abstract syntax trees.
Revised: The syntax of PDDL and the description logic is formalized in the form of an abstract syntax tree, and the semantics are formalized by deﬁning functions and predicates (e.g. deﬁning what is a valid plan, or what is the result of action execution) operating on the abstract syntax trees.

Original: Beyond the syntax and the semantics, this background theory contains general theorems which are reusable in any application that requires formal reasoning about PDDL and description logic.
Revised: Beyond the syntax and the semantics, this background theory contains general theorems which are reusable in any application that requires formal reasoning about PDDL and description logic.

Original: PDDL
Revised: PDDL

Original: For PDDL, we build on the work of Abdulaziz and Lammich (2018), who formalized its syntax and semantics in
Revised: For PDDL, we build on the work of Abdulaziz and Lammich (2018), who formalized its syntax and semantics in

Original: Isabelle/HOL.
Revised: Isabelle/HOL.

Original: Their theory uses a more general deﬁnition of PDDL, though, and is not restricted to STRIPS tasks with negation.
Revised: Their theory uses a more general deﬁnition of PDDL, though, and is not restricted to STRIPS tasks with negation.

Original: For example, in general PDDL action preconditions are ﬁrst-order formulas, objects are typed, and effects can have additional conditions.
Revised: For example, in general PDDL action preconditions are ﬁrst-order formulas, objects are typed, and effects can have additional conditions.

Original: In contrast, we focus on STRIPS, where preconditions are sets of literals, objects are untyped, and effects are given as two sets of atoms.
Revised: In contrast, we focus on STRIPS, where preconditions are sets of literals, objects are untyped, and effects are given as two sets of atoms.

Original: The reasoning in the more general PDDL setting is not problematic in theory but can introduce some complications when formally proving theorems about a given STRIPS domain.
Revised: The reasoning in the more general PDDL setting is not problematic in theory but can introduce some complications when formally proving theorems about a given STRIPS domain.

Original: When formalizing a proof in a STRIPS domain, reasoning about actions whose preconditions are sets of literals is more natural in interactive reasoning, as it more closely follows the pen-and-paper proofs.
Revised: When formalizing a proof in a STRIPS domain, reasoning about actions whose preconditions are sets of literals is more natural in interactive reasoning, as it more closely follows the pen-and-paper proofs.

Original: Furthermore, there is better support for automatically reasoning about sets in Isabelle/HOL.
Revised: Furthermore, there is better support for automatically reasoning about sets in Isabelle/HOL.

Original: Likewise, reasoning about types is inconvenient when we work in STRIPS domains where objects are untyped.
Revised: Likewise, reasoning about types is inconvenient when we work in STRIPS domains where objects are untyped.

Original: To be able to reason at the proper level when formally reasoning about STRIPS problems we built a framework of formal theorems and automated proof methods.
Revised: To be able to reason at the proper level when formally reasoning about STRIPS problems we built a framework of formal theorems and automated proof methods.

Original: This framework transforms proof obligations about PDDL domains, which contain formulas as preconditions, into proof obligations about sets.
Revised: This framework transforms proof obligations about PDDL domains, which contain formulas as preconditions, into proof obligations about sets.

Original: It also can automatically discharge any proof obligations about object types when reasoning about
Revised: It also can automatically discharge any proof obligations about object types when reasoning about

Original: STRIPS problem.
Revised: STRIPS problem.

Original: In our experience, using this framework signiﬁcantly simpliﬁes the process of formally proving statements about the Miconic domain.
Revised: In our experience, using this framework signiﬁcantly simpliﬁes the process of formally proving statements about the Miconic domain.

Original: In addition to changing perspective from general PDDL to STRIPS, our background theory deﬁnes the terms we introduced in the background section.
Revised: In addition to changing perspective from general PDDL to STRIPS, our background theory deﬁnes the terms we introduced in the background section.

Original: In particular, we deﬁne what an alive state is and prove properties for alive states, for example that alive states are reachable and that invariants that hold in the initial state also hold in all alive states.
Revised: In particular, we deﬁne what an alive state is and prove properties for alive states, for example that alive states are reachable and that invariants that hold in the initial state also hold in all alive states.

Original: In addition to being useful for reasoning about potential heuristics, this theory might ﬁnd application in certifying unsolvability of planning tasks.
Revised: In addition to being useful for reasoning about potential heuristics, this theory might ﬁnd application in certifying unsolvability of planning tasks.

Original: Formalizing Concept Languages
Revised: Formalizing Concept Languages

Original: Another contribution of our work is that we formalized the abstract syntax and the semantics of concept languages.
Revised: Another contribution of our work is that we formalized the abstract syntax and the semantics of concept languages.

Original: For instance, Listing 1 shows the formalization of the abstract syntax of the fragment of description logic we consider.
Revised: For instance, Listing 1 shows the formalization of the abstract syntax of the fragment of description logic we consider.

Revised: This listing shows how we use algebraic data-types, as implemented in Isabelle/HOL, to model the abstract syntax.

Revised: Algebraic data types are widely used in functional programming 2 .

Revised: They are used to elegantly recursively represent ﬁnite structures, e.g. trees.

Revised: In our case, a role could be a goal predicate, an inverse of another role, a transitive closure of another role, or a composition of two roles.

Original: The semantics, i.e. functions that assign meaning to  the  syntax are also formalized in Isabelle/HOL.
Revised: The latter three possibilities are recursively deﬁned, i.e. they are deﬁned in terms of roles. Also note that, next to each of the possibilities of the roles, we deﬁne a custom syntax which strongly matches the pen-and-paper format. Similar to roles, the abstract syntax tree of a concept is deﬁned recursively. Isabelle/HOL can automatically compute a lattice for such types, thus showing that the data type is well-deﬁned.

Revised: Based on that lattice, it derives induction principles which can be used for proving theorems by structural induction on a variable with the given data type.

Revised: The implementation in Isabelle/HOL for deriving these proofs is based on bounded natural functors (Traytel, Popescu, and Blanchette 2012).

Revised: The semantics, i.e. functions that assign meaning to the syntax are also formalized in Isabelle/HOL.

Original: The semantics of concepts are formalized in the form of a function that maps a state and a concept to a set  objects.
Revised: The semantics of concepts are formalized in the form of a function that maps a state and a concept to a set of objects.

Original: For roles an analogous function maps to sets of pairs of objects.
Revised: For roles an analogous function maps to sets of pairs of objects.

Original: Listingshows a sample of these functions.
Revised: Listing 2 shows a sample of these functions.

Revised: These functions are primitive recursive, i.e. they are deﬁned recursively in terms of recursive algebraic data types.

Revised: In particular, they are deﬁned using pattern matching .

Revised: For instance, the function role value is deﬁned to take, as arguments a role and a state.

Revised: It is deﬁned recursively in the role via pattern matching, where its value depends on the different possibilities a role could be.

Original: A main focus of our formalization of description logic was to develop a library which enables better (semi)automated reasoning.
Revised: In all cases, this function returns a set of pairs of objects, deﬁned using set comprehension. Note that the syntax used to deﬁne these sets is analogous to the pen-and-paper syntax one would use to deﬁne the sets. Similarly, we have another recursive function deﬁning the value of a concept. Isabelle/HOL is able to automatically prove termination for all these recursive functions.

Revised: Interested readers should consult Isabelle’s documentation, which summarises Isabelle/HOL’s function deﬁnition facilities, and Krauss (2009) for the theory behind it.

Revised: A main focus of our formalization of description logic was to develop a library which enables better (semi)automated reasoning.

Original: Since automation methods in
Revised: Since automation methods in

Original: Isabelle/HOL are chieﬂy based on Gentzen-style deduction, 1 we prove lemmas about concept languages which can act as Gentzen-style deduction rules.
Revised: Isabelle/HOL are chieﬂy based on Gentzen-style deduction, 3 we prove lemmas about concept languages which can act as Gentzen-style deduction rules.

Original: For instance, the lemma in Listing 3 is the analogue of conjunction introduction, but for concept languages.
Revised: For instance, the lemma in Listing 3 is the analogue of conjunction introduction, but for concept languages.

Revised: In particular, that theorem is an implication, which is written as a right-arrow.

Revised: The assumptions of that theorem, to the left of the arrow, lie between the square brackets and are separated by a semicolumn.

Revised: The conclusion of the theorem is to the right of the arrow.

Revised: Again, we use the set element relation ( ∈ ) and the other functions were deﬁned in the previous two listings.

Original: In addition to these general lemmas aimed to make automation easier, we also formalized the deﬁnitions related to generalized potential heuristics.
Revised: In addition to these general lemmas aimed to make automation easier, we also formalized the deﬁnitions related to generalized potential heuristics.

Original: This includes the deﬁnition of the value of a feature and the heuristic in a given state, what it means to be decreasing transition, and what it means to be a descending heuristic.
Revised: This includes the deﬁnition of the value of a feature and the heuristic in a given state, what it means to be decreasing transition, and what it means to be a descending heuristic.

Original: The overarching goal for this library is to provide background theory to aid in proving that a given heuristic is decreasing in a given domain.
Revised: The overarching goal for this library is to provide background theory to aid in proving that a given heuristic is decreasing in a given domain.

Original: Our main theorem in this section sets out sufﬁcient conditions to show that a transition is a decreasing transition , w.r.t.
Revised: Our main theorem in this section sets out sufﬁcient conditions to show that a transition is a decreasing transition , w.r.t.

Original: a given heuristic.
Revised: a given heuristic.

Original: To discuss it, we ﬁrst have to deﬁne some additional notation.
Revised: To discuss it, we ﬁrst have to deﬁne some additional notation.

Original: We say an object moves from concept C to C (cid:48) along a transition from state s to a state s (cid:48) if the object is in concept
Revised: We say an object moves from concept C to C (cid:48) along a transition from state s to a state s (cid:48) if the object is in concept

Original: C in state s and in concept C (cid:48) in s (cid:48) .
Revised: C in state s and in concept C (cid:48) in s (cid:48) .

Original: For the interpretation of a generalized potential heuristic as a tiered measure of progress, we deﬁne C h as the concepts used in the features of a heuristic h .
Revised: For the interpretation of a generalized potential heuristic as a tiered measure of progress, we deﬁne C h as the concepts used in the features of a heuristic h .

Original: We consider a partial order on C h based on the weight of the respective cardinality features in the heuristic.
Revised: We consider a partial order on C h based on the weight of the respective cardinality features in the heuristic.

Original: We say concept C is better than concept C (cid:48) if it occurs lower in this partial order, i.e. if it occurs with a lower weight in the heuristic.
Revised: We say concept C is better than concept C (cid:48) if it occurs lower in this partial order, i.e. if it occurs with a lower weight in the heuristic.

Original: Theorem 1 A transition from a state s to a state s (cid:48) leads to a decrease in the value of a generalized potential heuristic h using concepts C h if
Revised: Theorem 1 A transition from a state s to a state s (cid:48) leads to a decrease in the value of a generalized potential heuristic h using concepts C h if

Original: A1 the number of features in h is ﬁnite, A2 no feature occurs twice in the heuristic, A3 the concepts in C h are mutually exclusive, i e. no object can be in two different concepts of C h in any given state, A4 there are no objects that are in some concept C (cid:48)
Revised: A1 the number of features in h is ﬁnite, A2 no feature occurs twice in the heuristic, A3 the concepts in C h are mutually exclusive, i.e. no object can be in two different concepts of C h in any given state, A4 there are no objects that are in some concept C (cid:48)

Original: ∈ C h in state s (cid:48)
Revised: ∈ C h in state s (cid:48)

Original: but in no concept C ∈ C h in state s (i.e., no objects “spontaneously appear” in some concept during the state transition), A5 no objects move to worse concepts, and at least one moves to a strictly better concept.
Revised: but in no concept C ∈ C h in state s (i.e., no objects “spontaneously appear” in some concept during the state transition), A5 no objects move to worse concepts, and at least one moves to a strictly better concept.

Original: The proof of this theorem is moderately involved.

Original: The core argument involves performing a structural induction on the heuristic itself, i.e. an induction on the set of weight/feature pairs that constitute the heuristic, generalizing over the heuristic function as well as its values in the states s and s (cid:48) .

Original: datatype role =
Revised: datatype role =

Original: PredRole predicate | GoalPredRole predicate | Inverse role ("_ -1C " 29) | TransitiveClosure role ("_ +C " 29)| Composition role role (infix " ◦ C " 25) datatype concept =
Revised: PredRole predicate | GoalPredRole predicate | Inverse role ("_ -1C " 29) | TransitiveClosure role ("_ +C " 29) | Composition role role (infix " ◦ C " 25) datatype concept =

Original: Universe (" (cid:62) C ") | Empty (" ⊥ C ") | PredConcept predicate | GoalPredConcept predicate | Negation concept (" ¬ C _" [40] 40) | Union concept concept (infix " (cid:116) C " 30) | Intersection concept concept (infix " (cid:117) C " 35) | RestrictEx role concept (" ∃ C _.
Revised: Universe (" (cid:62) C ") | Empty (" ⊥ C ") | PredConcept predicate | GoalPredConcept predicate | Negation concept (" ¬ C _" [40] 40) | Union concept concept (infix " (cid:116) C " 30) | Intersection concept concept (infix " (cid:117) C " 35) | RestrictEx role concept (" ∃ C _.

Original: | RestrictFa role concept (" ∀ C _.
Revised: | RestrictFa role concept (" ∀ C _.

Original: _" 10)| RoleValueMap role role (infix " = C " 50)Listing
Revised: _" 10) | RoleValueMap role role (infix " = C " 50)

Original: Semantics of a concept language.

Original: fun role_value :: "role ⇒ state ⇒ (object × object) set" where [Table] "role_value (PredRole p) M = {(x,y) : untyped_object_tuples. (Atom (predAtm p [x,y]))
Revised: Note that we do not forbid objects from “spontaneously disappearing”.

Original: [Table]

Original: M}" |

Original: [Table]

Original: =

Original: [Table]

Original: x,y) : [Table] (atoms (goal P))}" | [Table]
Revised: This is not a problem as our weights are nonnegative so objects leaving all concepts of C h can only decrease the heuristic value.

Original: Inverse

Original: =

Original: [Table]

Original: [Table]

Original: [Table]

Original: [Table]

Original: [Table]

Original: [Table] [Table] M) [Table]
Revised: The proof of this theorem is moderately involved and takes around 500 lines in Isabelle.

Original: " | "

Original: [Table]

Original: [Table]

Original: [Table]

Original: [Table]

Original: [Table]

Original: [Table]

Original: [Table]

Original: [Table]

Original: [Table]

Original: [Table]

Original: " | "

Original: [Table]

Original: [Table]

Original: [Table] [Table] [Table] lemma concept_valueI:
Revised: The core argument involves performing a structural induction on the heuristic itself, i.e. an induction on the set of weight/feature pairs that constitute the heuristic, generalizing over the heuristic function as well as its values in the states s and s (cid:48) .

Original: [Table]

Original: The main goal of proving this theorem is to prove that a heuristic is descending for a given domain.
Revised: The main goal of proving this theorem is to prove that a heuristic is descending for a given domain.

Original: The ﬁnal theorem in our background theory shows that if A1–A3 are satisﬁed and for every alive state in the domain there is a successor satisfying A4–A5, the heuristic is descending.
Revised: The ﬁnal theorem in our background theory states that if A1–A3 are satisﬁed and for every alive state in the domain there is a successor satisfying A4–A5, the heuristic is descending.

Original: This leaves A1–A5 as the main proof obligations for the user to show that a given heuristic is descending for a given domain.
Revised: This leaves A1–A5 as the main proof obligations for the user to show that a given heuristic is descending for a given domain.

Original: Domain- and Heuristic-Speciﬁc Reasoning
Revised: Domain- and Heuristic-Speciﬁc Reasoning

Original: The theorems we described so far  are independent of a speciﬁc domain or heuristic.
Revised: The theorems we described so far (Theorem 1 and all other theorems about PDDL, DL, and concept languages) are independent of a speciﬁc domain or heuristic.

Original: We now describe another important part of our contribution that supports formal reasoning about a given heuristic and domain.
Revised: We now describe another important part of our contribution that supports formal reasoning about a given heuristic and domain.

Original: Our tools can automatically generate deﬁnitions for a PDDL domain and a heuristic as an Isabelle/HOL theory.
Revised: Our tools can automatically generate deﬁnitions for a PDDL domain and a heuristic as an Isabelle/HOL theory.

Original: These deﬁnitions are the representation about which the user reasons and proves theorems.
Revised: These deﬁnitions are the representation about which the user reasons and proves theorems.

Original: Our tooling also automatically proves many properties about the domain and the heuristic.
Revised: Our tooling also automatically proves many properties about the domain and the heuristic.

Original: These properties are then used in the interactive proofs done by the user.
Revised: These properties are then used in the interactive proofs done by the user.

Original: PDDL
Revised: PDDL

Original: Given a domain, described in a PDDL ﬁle, we built tooling that parses the different elements of the domain into Isabelle/HOL deﬁnitions.
Revised: Given a domain, described in a PDDL ﬁle, we built tooling that parses the different elements of the domain into Isabelle/HOL deﬁnitions.

Original: In addition to the PDDL domain, we also parse domain invariants and domain assumptions.
Revised: In addition to the PDDL domain, we also parse domain invariants and domain assumptions.

Original: Each invariant is parsed into a domain assumption that the statement holds for the initial state and a theorem stating that this is indeed an invariant.
Revised: Each invariant is parsed into a domain assumption that the statement holds for the initial state and a theorem stating that this is indeed an invariant.

Original: In the current state of our systems, these statements about the invariants are not proved.
Revised: In the current state of our systems, these statements about the invariants are not proved.

Original: However, the invariants we use for the Miconic example are very simple statements and we do not expect major difﬁculties proving them interactively.
Revised: However, the invariants we use for the Miconic example are very simple statements and we do not expect major difﬁculties proving them interactively.

Original: In general, proving invariants is semi-decidable, as any ﬁrst-order logic formula can be written as an invariant.
Revised: In general, proving invariants is semi-decidable, as any ﬁrst-order logic formula can be written as an invariant.

Original: To express the domain assumptions, we make use of a feature in Isabelle/HOL called a locale (Ballarin 2014).
Revised: To express the domain assumptions, we make use of a feature in Isabelle/HOL called a locale (Ballarin 2014).

Original: Locales are a way to structure theories in Isabelle/HOL.
Revised: Locales are a way to structure theories in Isabelle/HOL.

Original: In our context here, the most interesting aspect of locales is that assumptions speciﬁed in a locale are implicit assumptions for any theorem within the locale.
Revised: In our context here, the most interesting aspect of locales is that assumptions speciﬁed in a locale are implicit assumptions for any theorem within the locale.

Original: We prove all our theorems within the domain’s locale, so all domain assumptions are implicit assumptions to all theorems in the locale, i.e. to all the theorems about the given domain.
Revised: We prove all our theorems within the domain’s locale, so all domain assumptions are implicit assumptions to all theorems in the locale, i.e. to all the theorems about the given domain.

Original: In addition to representing the domain, the invariants, and the domain assumptions, we also automatically prove technical lemmas that are needed to ease the automation of the proofs.
Revised: In addition to representing the domain, the invariants, and the domain assumptions, we also automatically prove technical lemmas that are needed to ease the automation of the proofs.

Original: For instance, we generate lemmas stating that all predicates in the domain have different names.
Revised: For instance, we generate lemmas stating that all predicates in the domain have different names.

Original: Generalized Potential Heuristics
Revised: Generalized Potential Heuristics

Original: Similar to what we do with the PDDL domain, our system also parses the given description of the concepts and the heuristic and translates them into Isabelle/HOL deﬁnitions.
Revised: Similar to what we do with the PDDL domain, our system also parses the given description of the concepts and the heuristic and translates them into Isabelle/HOL deﬁnitions.

Original: We also prove many technical lemmas about the concepts in the given domain.
Revised: We also prove many technical lemmas about the concepts in the given domain.

Original: In particular, we prove that concepts and features have different names.
Revised: In particular, we prove that concepts and features have different names.

Original: We also describe the different concepts in features of the heuristic, and the partial order between them based on the weights.
Revised: We also describe the different concepts in features of the heuristic, and the partial order between them based on the weights.

Original: To prove that the given heuristic is descending, we show that the assumptions of Theorem 1 apply to the domain and the heuristic.
Revised: To prove that the given heuristic is descending, we show that the assumptions of Theorem 1 apply to the domain and the heuristic.

Original: Assumptions A1 and A2 are easy to show automatically for the given heuristic.
Revised: Assumptions A1 and A2 are easy to show automatically for the given heuristic.

Original: Automating the proof of assumption A3 is more problematic.
Revised: Automating the proof of assumption A3 is more problematic.

Original: Showing that two concepts C 1 and C 2 cannot overlap is equivalent to showing that the concept C 1 (cid:117) C 2 is not satisﬁable.
Revised: Showing that two concepts C 1 and C 2 cannot overlap is equivalent to showing that role_value : "role ⇒ state ⇒ (object × object) set" [Table] [Table]

Revised: [Table]

Revised: [Table]

Revised: [Table]

Revised: [Table]

Revised: [Table]

Revised: [Table]

Revised: [Table]

Revised: [Table]

Revised: [Table]

Revised: [Table]

Revised: [Table]

Revised: Listing 3: Conjunction introduction for our concept language.

Revised: lemma concept_valueI:

Revised: [Equation]

Revised: [Table]

Revised: [Equation]

Revised: [Table]

Revised: [Equation]

Original:  This problem is undecidable for most fragments of description logic that include role-value maps (i.e., concepts like ( R 1 = R 2 ) )
Revised: [Table] [Equation] the concept C 1 (cid:117) C 2 is not satisﬁable. This problem is undecidable for most fragments of description logic that include role-value maps (i.e., concepts like ( R 1 = R 2 ) )

Original: (SchmidtSchauß 1989).
Revised: (SchmidtSchauß 1989).

Original: Without role-value maps, our fragment of description logic is contained in ALCIO reg where satisﬁability checks are EXPTIME-complete (De Giacomo 1995) and is thus decidable.
Revised: Without role-value maps, our fragment of description logic is contained in ALCIO reg where satisﬁability checks are EXPTIME-complete (De Giacomo 1995) and is thus decidable.

Original: For domains where a descending generalized potential heuristic can be expressed without role-value maps (e.g. this is the case in Miconic), a complete decision procedure could be implemented in Isabelle/HOL to automatically prove that concepts are mutually exclusive.
Revised: For domains where a descending generalized potential heuristic can be expressed without role-value maps (e.g. this is the case in Miconic), a complete decision procedure could be implemented in Isabelle/HOL to automatically prove that concepts are mutually exclusive.

Original: Currently, we do not use such a complete decision procedure but rely on an incomplete method of Isabelle/HOL.
Revised: Currently, we do not use such a complete decision procedure but rely on an incomplete method of Isabelle/HOL.

Original: This incomplete method successfully discharges the proof of A3 for Miconic.
Revised: This incomplete method successfully discharges the proof of A3 for Miconic.

Original: However, we are not sure whether this would work for other domains.
Revised: However, we are not sure whether this would work for other domains.

Original: An additional complication could be that proving A3 needs the domain assumptions – as we stated, every theorem we prove has the domain assumptions as implicit assumptions due to our locale.
Revised: An additional complication could be that proving A3 needs the domain assumptions – as we stated, every theorem we prove has the domain assumptions as implicit assumptions due to our locale.

Original: This would be problematic as domain assumptions are arbitrary ﬁrst-order formulas, so proving A will then be a ﬁrst-order theorem proving task.
Revised: This would be problematic as domain assumptions are arbitrary ﬁrst-order formulas, so proving A will then be a ﬁrst-order theorem proving task.

Original: The Interactive Part: Showing the Existence of an Improving Transition
Revised: The Interactive Part: Showing the Existence of an Improving Transition

Original: The remaining part of the proof is to show that assumptions
Revised: The remaining part of the proof is to show that assumptions

Original: A4 and A5 of Theorem 1 hold for every alive state.
Revised: A4 and A5 of Theorem 1 hold for every alive state.

Original: Together with the proofs of A1–A3 described in the previous section, we can then conclude that in every alive state there is  action whose application decreases the heuristic value.
Revised: Together with the proofs of A1–A3 described in the previous section, we can then conclude that in every alive state there is an action whose application decreases the heuristic value.

Original: We prove assumptions A4 and A5 by case analysis.
Revised: We prove assumptions A4 and A5 by case analysis.

Original: In particular, we use an ordering C 1 , C 2 , . . .
Revised: In particular, we use an ordering C 1 , C 2 , . . .

Original: , C n over the concepts occurring in the heuristic description.
Revised: , C n over the concepts occurring in the heuristic description.

Original: We then have n cases, where each case 1 ≤ i ≤ n assumes that concepts
Revised: We then have n cases, where each case 1 ≤ i ≤ n assumes that concepts

Original: C 1 , C 2 , . .
Revised: C 1 , C 2 , . .

Original: , C i − 1 are empty, and concept C i is not empty in a ﬁxed alive state s .
Revised: , C i − 1 are empty, and concept C i is not empty in a ﬁxed alive state s .

Original: We prove automatically that at least an object exists in C i in state s .
Revised: We prove automatically that at least an object exists in C i in state s .

Original: For this object, we automatically prove properties based on the concept that it is in.
Revised: For this object, we automatically prove properties based on the concept that it is in.

Original: Example 4 For concept “not-boarded-has-lift”, we show that an object p exists that satisﬁes passenger ( p ) ∈ s, served ( p ) / ∈ s, boarded ( p ) / ∈ s, and
Revised: Example 4 For concept “not-boarded-has-lift”, we show that an object p exists that satisﬁes passenger ( p ) ∈ s, served ( p ) / ∈ s, boarded ( p ) / ∈ s, and

Original: ∃ f. ( origin ( p, f ) ∈
Revised: ∃ f. ( origin ( p, f ) ∈

Original: s ∧ lift-at ( f ) ∈ s ) .
Revised: s ∧ lift-at ( f ) ∈ s ) .

Original: Currently, we deﬁne these properties of the witness object manually, but they closely follow the structure of the concept and could be derived automatically.
Revised: Currently, we deﬁne these properties of the witness object manually, but they closely follow the structure of the concept and could be derived by straightforward syntactic analysis.

Original: The user then chooses an action and interactively proves that it is a witness action, i.e., that the successor reached through this action satisﬁes A4 and A5.
Revised: The user then chooses an action and interactively proves that it is a witness action, i.e., that the successor reached through this action satisﬁes A4 and A5.

Original: Choosing an action consists of selecting an action schema and picking its parameters.
Revised: Choosing an action consists of selecting an action schema and picking its parameters.

Original: The witness action in general cannot be derived automatically.
Revised: The witness action in general cannot be derived automatically.

Original: While it would be possible to test all different action schemas, selecting the parameters is not as straightforward.
Revised: While it would be possible to test all different action schemas, selecting the parameters is not as straightforward.

Original: For example, a parameter could simply be the object from the non-empty concept, but in general its existence could also be derived from nested existentially quantiﬁed concepts or domain assumptions.
Revised: For example, a parameter could simply be the object from the non-empty concept, but in general its existence could also be derived from nested existentially quantiﬁed concepts or domain assumptions.

Original: Since it could, for instance, be in the transitive closure of a role, there is no complete ﬁnite method to enumerate all possible parameter choices.

Original: Next,the user has to show that the precondition of the witness action is always satisﬁed in any alive state of the current case.
Revised: Next, the user has to show that the precondition of the witness action is always satisﬁed in any alive state of the current case.

Original: In this proof, the user can use the domain assumptions, the assumptions about the current case (i.e., which concepts are empty/non-empty), and the properties of the object in the non-empty concept.
Revised: In this proof, the user can use the domain assumptions, the assumptions about the current case (i.e., which concepts are empty/non-empty), and the properties of the object in the non-empty concept.

Original: Finally, the user has to show three facts about the transition induced by applying the witness action in an alive state satisfying the current case:
Revised: Finally, the user has to show three facts about the transition induced by applying the witness action in an alive state satisfying the current case:

Original: for each concept in the heuristic, if an object was in this concept before applying the action, afterwards it is not in a worse concept.
Revised: for each concept in the heuristic, if an object was in this concept before applying the action, afterwards it is not in a worse concept.

Original: at least one object moves to a better concept.
Revised: at least one object moves to a better concept.

Original: no object is added to any concept that was not in a concept before.
Revised: no object is added to any concept that was not in a concept before.

Original: To show that, we show that for each heuristic concept that if an object is in the concept after the application, then it was in a heuristic concept before the action application.
Revised: To show that, we show that for each heuristic concept that, if an object is in the concept after the application, then it was in a heuristic concept before the action application.

Original: Again the proofs can use the domain and case assumptions, properties of the object in the non-empty concept, but additionally they can use the fact that the precondition of the witness action is satisﬁed to derive further information about the state.
Revised: Again the proofs can use the domain and case assumptions, properties of the object in the non-empty concept, but additionally they can use the fact that the precondition of the witness action is satisﬁed to derive further information about the state.

Original: We automated the proof of each of the three proof obligations we described above.
Revised: We automated the proof of each of the three proof obligations we described above.

Original: We implemented proof strategies within Isabelle using the Eisbach framework (Matichuk,
Revised: We implemented proof methods within Isabelle using the Eisbach framework (Matichuk,

Original: Murray, and Wenzel 2016) to automate these proofs.
Revised: Murray, and Wenzel 2016) to automate these proofs.

Original: We have no theoretical guarantees on the completeness of these methods, butin each case a single proof strategy works for all cases of Miconic.
Revised: We have no theoretical guarantees on the completeness of these methods, but a single proof method works for all cases of Miconic.

Original: Together, the three properties show assumptions A4 and
Revised: Together, the three properties show assumptions A4 and

Original: A5 which allows the user to apply Theorem 1 to conclude that the heuristic value decreases while applying the witness action.
Revised: A5 which allow the user to apply Theorem 1 to conclude that the heuristic value decreases while applying the witness action.

Original: The last step in the proof, which the user has to perform interactively, is to combine all the previous results to prove that the heuristic has a decreasing successor in every alive state.
Revised: The last step in the proof, which the user has to perform interactively, is to combine all the previous results to prove that the heuristic has a decreasing successor in every alive state.

Original: If the default case split was used, this part of the proof would always look the same so it can be generated automatically.
Revised: If the default case split was used, this part of the proof would always look the same so it can be generated automatically.

Original: This then shows that the heuristic is a tiered measure of progress.
Revised: This then shows that the heuristic is a tiered measure of progress.

Original: This can in turn be used with the theorem we discussed earlier to show that the heuristic is indeed descending.
Revised: This can in turn be used with the theorem we discussed earlier to show that the heuristic is indeed descending.

Original: Conclusion
Revised: Conclusion

Original: We showed ﬁrst results of our tool to automate proofs of performance guarantees using generalized heuristics in Isabelle/HOL.
Revised: We showed ﬁrst results of our tool to automate proofs of performance guarantees using generalized heuristics in Isabelle/HOL.

Original: In particular, we show an interactive theorem proving method for planning domains and generalized potential heuristics.
Revised: In particular, we show an interactive theorem proving method for planning domains and generalized potential heuristics.

Original: So far, our scope is limited to those heuristics representing tiered measures of progress expressed with mutually exclusive concepts.
Revised: So far, our scope is limited to those heuristics representing tiered measures of progress expressed with mutually exclusive concepts.

Original: We showed the viability of the system by proving that a heuristic for the domain Miconic is indeed descending.
Revised: We showed the viability of the system by proving that a heuristic for the domain Miconic is indeed descending.

Original: The next steps of our work are to automate some of the remaining parts of the proofs where possible.
Revised: The next steps of our work are to automate some of the remaining parts of the proofs where possible.

Original: For example, proving that all concepts are mutually exclusive could be automated if we restrict the description logic to no longer allow role-value maps.
Revised: For example, proving that all concepts are mutually exclusive could be automated if we restrict the description logic to no longer allow role-value maps.

Original: Finding parameters for a witness action is an interesting problem as well.
Revised: Finding parameters for a witness action is an interesting problem as well.

Original: While it is generally undecidable, incomplete methods that systematically try objects based on the non-empty concept and the domain assumptions could already cover many interesting cases.
Revised: While it is potentially semi-decidable, incomplete methods that systematically try objects based on the non-empty concept and the domain assumptions could already cover many interesting cases.

Original: In the long run, our framework could be used more generally for other proofs about PDDL domains and generalized heuristics. 
Revised: In the long run, our framework could be used more generally for other proofs about PDDL domains and generalized heuristics. Acknowledgments

Revised: This work was supported by the Swiss National Science

Revised: Foundation (SNSF) as part of the project “Certiﬁed Correctness and Guaranteed Performance for Domain-Independent

Revised: Planning” (CCGP-Plan) and by the Deutsche Forschunggemeinschaft Reinhart Koselleck project NI 491/16-1 “Veriﬁzierte Algorithmenanalyse”.

Revised: Moreover, this research was partially supported by TAILOR, a project funded by the

Revised: EU Horizon 2020 research and innovation programme under grant agreement no. 952215.