Procedural scheduling documentation (#184)

* Procedural scheduling docs

* fix broken links in docs

* Update deserialization docs

* Clarify constraint edsl docs

* No longer recommend CLI for goal upload

* Link to generated kotlin docs

* Hide unimplemented docs

---------

Co-authored-by: dandelany <[email protected]>

docs/glossary.md

@@ -35,7 +35,7 @@ This is an alphabetized glossary of common term definitions used throughout the
 
 1. **Constraint Checking** - A downstream analysis of a simulation dataset that evaluates a set of constraints and returns time windows of violation.
 
-1. **Constraint** - An expression built up with the [Aerie constraints](../constraints/introduction) eDSL, which evaluates to a set of windows during which the condition(s) defined by the expression is true or false. Aerie supports various constraint types such as safe ranges for resources or necessary pre-conditions for safe execution of activities. Aerie constraints is a mechanism to represent and check many flight rule types.
+1. **Constraint** - An expression built up with the [Aerie constraints](../scheduling-and-constraints/declarative/constraints/introduction) eDSL, which evaluates to a set of windows during which the condition(s) defined by the expression is true or false. Aerie supports various constraint types such as safe ranges for resources or necessary pre-conditions for safe execution of activities. Aerie constraints is a mechanism to represent and check many flight rule types.
 
 ## D
 

docs/mission-modeling/activity-types/durations.md

@@ -1,6 +1,6 @@
 # Duration Types
 
-The [Aerie scheduler](../../../scheduling/introduction) places activities in a plan to try to achieve scheduling goals, and to do that it must know the activity's duration. Since an activity's effect model is a black box, without more information the scheduler has to simulate the activity to see how long it lasts. This can be very expensive and best to avoid if possible. Satisfying temporal constraints associated with the scheduling of an activity (e.g. "activity A must end before activity B") may lead to multiple simulations to compute duration, and thus require even more computation time.
+The [Aerie scheduler](../../scheduling-and-constraints/declarative/scheduling/introduction.mdx) places activities in a plan to try to achieve scheduling goals, and to do that it must know the activity's duration. Since an activity's effect model is a black box, without more information the scheduler has to simulate the activity to see how long it lasts. This can be very expensive and best to avoid if possible. Satisfying temporal constraints associated with the scheduling of an activity (e.g. "activity A must end before activity B") may lead to multiple simulations to compute duration, and thus require even more computation time.
 
 However, it is possible to provide information about how the duration of an activity is determined to help the scheduler. The duration of an activity can be one of the following:
 

docs/overview/concept-of-operations.mdx

@@ -12,8 +12,8 @@ Aerie is designed to address the following capability gaps:
 - Allow missions to provide a web deployment of a planning tool such that operators with limited programming skills can create valid activity plans and run simulations
 - Support real time collaboration and and parallel hypothesis testing such that many more iterations of an activity plan can be tested within the same time frame
 - Allow automation and manual modifications to coexist throughout the planning process
-- Provide a low-code constraint checking mechanism to validate simulation outputs which can be largely automated
-- Provide a low-code scheduling mechanism that can scaffold parts of or generate complete activity plans according to goal snippets
+- Provide a flexible constraint checking mechanism to validate simulation outputs which can be largely automated
+- Provide a flexible scheduling mechanism that can scaffold parts of or generate complete activity plans according to goal snippets
 - Support an easy-to-use and verified translation from activities to sequences of commands that are recognized by the flight system
 
 Note that none of the capabilities above are completely new. Other software solutions have offered pieces of the listed capabilities in different or more limited flavors. Aerie's mission is to cover as many key steps in the whole activity planning and sequencing workflow in one deployed tool with dedicated components.

docs/overview/software-design-document.mdx

@@ -892,7 +892,7 @@ DSL, Merlin has little to no ability to see the actual Java code
 comprising a mission model. Merlin must instead make inferences about
 the mission model based on its observable behavior.
 
-Merlin is a spiritual successor to the 
+Merlin is a spiritual successor to the
 [Blackbird](https://trs.jpl.nasa.gov/handle/2014/52245) planning
 system, which similarly uses Java for activity and resource modeling.
 Blackbird's design shed light on the myriad choices made in designing
@@ -1225,7 +1225,7 @@ constraint expression operators, while the leaf nodes represent the
 operands. For example, operator nodes enable expressions such as 'or',
 'and', 'less than', 'greater than', while the operands are simulated
 resource profiles and activity instances. See our [constraints
-documentation](../../constraints/examples) for complete examples.
+documentation](../../scheduling-and-constraints/declarative/constraints/examples) for complete examples.
 
 ## Meta-Programming (Annotations Processing)
 

docs/constraints/concepts.md → docs/scheduling-and-constraints/declarative/constraints/concepts.md

@@ -8,7 +8,7 @@ Profiles represent functions over time to a specific type, and usually come from
 
 Real profiles are for integers and floating point numbers, and provide methods for some basic math operations like addition and derivatives. Discrete profiles are for everything else, like strings or objects.
 
-Profiles can have _gaps_, or intervals where the value is unknown. This comes up most often when dealing with [external datasets](../../planning/external-datasets). In most cases it is best to apply a default value to a profile's gaps ASAP using the `profile.assignGaps(defaultValue)` method.
+Profiles can have _gaps_, or intervals where the value is unknown. This comes up most often when dealing with [external datasets](../../../../planning/external-datasets). In most cases it is best to apply a default value to a profile's gaps ASAP using the `profile.assignGaps(defaultValue)` method.
 
 ## Windows
 
@@ -32,4 +32,4 @@ Not all constraints are based solely off of a `Windows` object. The main excepti
 
 ## Mental Model for Evaluation
 
-A constraint doesn't directly query simulation data, or directly return violations. Instead, your constraint code defines an expression to be interpreted by Aerie. The exact implementation details don’t matter for constraint authors, but for this reason you cannot directly inspect a profile's values or a plan's activities. This is also why there are no plans to support querying external profiles directly from a web request or filesystem access inside the constraint code. For that, see the [external dataset documentation](../../planning/external-datasets).
+A constraint doesn't directly query simulation data, or directly return violations. Instead, your constraint code defines an expression to be interpreted by Aerie. The exact implementation details don’t matter for constraint authors, but for this reason you cannot directly inspect a profile's values or a plan's activities. This is also why there are no plans to support querying external profiles directly from a web request or filesystem access inside the constraint code. For that, see the [external dataset documentation](../../../../planning/external-datasets).

docs/constraints/introduction.mdx → docs/scheduling-and-constraints/declarative/constraints/introduction.mdx

@@ -9,10 +9,10 @@ If a constraint does not hold true at any point in a simulation, this is conside
 
 All constraints are associated with either a mission model or a specific plan.
 If associated with a model, a constraint will be applied to all plans made with that model.
-If associated with a plan, it will only applied to the plan, and it will have access to any [external datasets](../../planning/external-datasets) associated with the plan as well.
+If associated with a plan, it will only applied to the plan, and it will have access to any [external datasets](../../../../planning/external-datasets) associated with the plan as well.
 
 :::tip
 
-To learn how to add constraints via the Aerie API, see our [API documentation](../../api/examples/constraints).
+To learn how to add constraints via the Aerie API, see our [API documentation](../../../../api/examples/constraints).
 
 :::

docs/scheduling/goals.mdx → docs/scheduling-and-constraints/declarative/scheduling/goals.mdx

@@ -4,7 +4,7 @@ This document describes different scheduling goals available in Aerie and how to
 
 :::caution
 
-Activities with [uncontrollable durations](../../mission-modeling/activity-types/parameters#duration-types) have been found to behave somewhat unpredictably in terms of when they are placed.
+Activities with [uncontrollable durations](../../../../mission-modeling/activity-types/parameters#duration-types) have been found to behave somewhat unpredictably in terms of when they are placed.
 This has to do with how temporal constraints interact with the unpredictability of the durations.
 Finding when an activity will start while subject to temporal constraint involves search.
 
@@ -256,7 +256,7 @@ Behavior: The activity finder is being used to match against any existing PeelBa
 
 :::caution
 
-If the end is unconstrained while the activity has an [uncontrollable duration](../../mission-modeling/activity-types/parameters#duration-types), the scheduler may fail to place the activity.
+If the end is unconstrained while the activity has an [uncontrollable duration](../../../../mission-modeling/activity-types/parameters#duration-types), the scheduler may fail to place the activity.
 To work around this, add an `endsWithin` constraint that encompasses your expectation for the duration of the activity - this will help the scheduler narrow the search space.
 
 :::

docs/scheduling/introduction.mdx → docs/scheduling-and-constraints/declarative/scheduling/introduction.mdx

@@ -1,8 +1,8 @@
 # Scheduling
 
-This guide explains how to use the scheduling service with the latest version of Aerie.
+This guide explains how to use the declarative scheduling service with Aerie.
 The scheduling service allows you to add activities to a plan based on goals that you define (this is something called "goal based scheduling").
-Goals are defined in [TypeScript](https://www.typescriptlang.org/) using an embedded domain specific language (EDSL) provided by Aerie.
+Declarative Goals are defined in [TypeScript](https://www.typescriptlang.org/) using an embedded domain specific language (EDSL) provided by Aerie.
 
 :::note
 

docs/scheduling/run-scheduling.mdx → docs/scheduling-and-constraints/execution.mdx

@@ -1,35 +1,11 @@
-# Run Scheduling
+# Execution
 
-## Scheduling Specification
+## Constraints
 
-After you have created one or several goals, you will see them in the scheduling pane of the plan in Aerie UI.
+Constraints can be checked inside the main plan view by opening the `Constraints` pane and clicking the checklist icon
+in the top right of the pane. Alternatively, you can hover over `Constraints` in the top bar and click "Check Constraints".
 
-The Aerie scheduler accepts a list of goals, and tries to satisfy them one by one by adding activities to your plan. We refer to this list of goals as a **scheduling specification**. Aerie creates one scheduling specification per plan. A goal's priority is a number reflecting that goal's position in the scheduling specification. The first goal will always have priority `0`, and the n-th goal will always have priority `n - 1`. Within a scheduling specification, a scheduling goal can be toggled enabled or disabled. A disabled scheduling goal will be excluded from scheduling execution. The priority ordering of the scheduling goals remains unchanged whether a goal is enabled or disabled.
-
-import schedulingSpecification from './assets/scheduling-specification.png';
-
-<figure>
-  <img alt="Aerie UI - Scheduling Specification" src={schedulingSpecification} />
-  <figcaption>Figure 1: Aerie UI Scheduling Specification</figcaption>
-</figure>
-
-In this image, you can see a specification with three goals. Goal 1 has priority `0`, and goal 3 has priority `2`. You can modify the priorities directly by typing numbers or use the arrows. You can disable a goal by toggling it off with the checkbox.
-
-:::caution
-
-You must use priorities in the `[0, n-1]` range, `n` being the number of goals.
-
-:::
-
-:::caution
-
-A given goal may be a part of zero or one specification - goals may not be shared between multiple specifications. If you need to do this, make a copy of the goal.
-
-There may be at most one specification at a time associated with a given plan.
-
-:::
-
-## Running the Scheduler
+## Scheduling
 
 To run the scheduler, click on the play button:
 
@@ -71,7 +47,7 @@ import schedulingSuccess from './assets/scheduling-success.png';
 - `174` means that there are `174` activity directives that contribute to the satisfaction of the goal
 - `+3` means that 3 new activities have been inserted in the plan to satisfied the goal during the last scheduling run
 
-## Running a Scheduling Analysis
+### Running a Scheduling Analysis
 
 The scheduler has an analysis mode that will evaluate the satisfaction of goals but will not place any new activities. To run the scheduler in analysis mode, click on the "analysis" button:
 

docs/scheduling-and-constraints/introduction.mdx

@@ -0,0 +1,43 @@
+# Scheduling & Constraints
+
+Aerie provides related frameworks for defining constraints and scheduling new activities in the plan, and two implementations
+of those frameworks: one for arbitrary procedures that run on the JVM, and a legacy system based on a declarative Typescript eDSL
+(embedded Domain-Specific Language). Both frameworks are documented here, but new users are encouraged to focus on
+creating JVM procedures. The declarative eDSL is significantly less capable, and the difference in capabilities is only expected to
+grow.
+
+## Constraints
+
+Constraints represent what is nominal for a plan or mission model, and when executed, the UI will display "violations"
+whenever the plan or model is off-nominal. They don't alter the behavior of the simulation engine or scheduler; they
+just serve as a warning, indicating that some requirement - perhaps a flight rule - was broken.
+
+## Scheduling
+
+The scheduler allows users to automate the creation of new activities, to remove some cognitive load from planners. A
+scheduling specification contains a list of goals and rules with a priority order; during a scheduling run, they are
+executed one at a time, starting from a priority of 0 and increasing from there.
+
+### Procedural Goals
+
+Procedural goals directly edit the plan, creating new activities at definite (grounded) times. They
+can simulate potential changes to the plan, but aren't required to. In fact, a scheduling specification composed entirely
+of procedures might run in its entirety without performing any simulations, potentially at the cost of optimality or even
+soundness.
+
+### eDSL Goals
+
+eDSL goals are more declarative, in that they don't allow you to directly create grounded activities; instead they allow
+you to describe a pattern of activities that should be present in the plan. If the pattern isn't found, the goal tries to
+create it for you. Currently eDSL goals are simpler to write than procedural goals, for patterns that they can represent.
+Many goals are more complex than can be represented in the eDSL, and will have to be written as a procedure.
+
+### Global Conditions
+
+Global scheduling conditions (or sometimes just "conditions") are supplemental pieces of code that define when scheduling
+goals can and cannot place activities. They are incorporated into the solver when attempting to resolve conflicts as
+a substitute for constraints. This is because it is too difficult to respect constraints during scheduling; constraints
+only indicate that something went wrong, not what caused it or how to fix it. So in cases when the scheduler keeps violating
+constraints, users can create a condition as a heuristic to help it satisfy the constraint.
+
+Conditions will be accessible to scheduling rules, but will be non-binding.

docs/scheduling-and-constraints/management.mdx

@@ -0,0 +1,37 @@
+# Management
+
+## Creating and Updating
+
+The recommended setup is to store goals/rules/conditions/constraints (hereafter called "peripheral code")
+in one or more repositories outside Aerie, and uploading
+them through the UI.
+
+For example, after creating a new goal as described in the following pages, you can upload it with the UI by selecting
+`New` on the `Scheduling` option in main top-left dropdown. Or, you can upload it with an automatic association with your
+plan by opening the `Scheduling Goals` pane in your plan, and navigating to `Manage Goals -> New`. Here you have the
+option to either upload a JAR file, or copy-paste a typescript eDSL file.
+
+## Model and Plan Association
+
+In Aerie, peripherals live independently of plans and models, and can be associated with
+any number of plans and models, or none at all. Each model and plan has a scheduling specification and a constraints
+specification, which is simply a list of peripherals to run during the scheduling or constraints actions, respectively.
+
+Model specifications are never run directly, and instead populate the default spec for any plans created from that model.
+So if a particular constraint is widely applicable to all plans made from a particular model, you can associate it with
+the model by navigating to `Models -> <select your model> -> Edit details ... -> Constraints -> Library`. Click the checkbox
+on your constraint and select `Save`. Now any new plans made with this model will include your constraint in its specification.
+
+Peripherals that don't apply to all plans for a model can be associated with individual plans too. In the main plan view,
+navigate to the `Scheduling Goals` or `Constraints` pane, then click `Manage`. Click the checkbox for your peripheral and
+select `Save`.
+
+## Version Locking
+
+Peripheral associations can be locked to a specific revision, on either the model or plan specification. In the specification,
+you can change `Always use latest` to a revision number of your choice.
+
+## Deleting
+
+Peripherals can be deleted in the UI by navigating to the `Scheduling` or `Constraints` view in the top left, and deleting
+them there. This action can't be done if the peripheral is being used by a plan or model.