Test scheduling rules before adding them

The initial project concerned turning an annual plan into structured calendar events, with views and exports for different audiences. Calendar feeds and printable exports were part of that scope from the beginning.

PitchAI built a planner in which an event can be edited, retained in a calendar and year-plan view, and exported as an iCal file. The export preserves the event's identifier, title and start and end times.

A later, separate rule-editor demonstration addressed another planning task: expressing a scheduling requirement precisely enough to test it. A person describes the requirement and can answer follow-up questions in the same conversation.

The assistant prepares a rule against the agenda properties the system models. Unsupported properties require clarification or a model change; they cannot simply be substituted with an unrelated field to make the proposal appear ready.

The server compiles the proposed rule, reruns its test scenarios and simulates its effect on example activities. It checks referenced rules, allowed fields and actions, and failed execution results. Approval requires both the assistant's readiness and passing server checks.

The simulations show how the proposal behaves on the supplied examples. They give the reviewer concrete cases to inspect, without establishing that every possible scheduling situation has been covered.

Selecting Add Rule triggers another server review. The displayed proposal must match the saved proposal, validation must still pass, and the rule collection must be the same collection against which the proposal was prepared.

The new rule and its review record are saved together. That record includes clarification answers, simulated effects, validation reasons and the time of addition. If the collection has changed, the write is rejected so the proposal can be reviewed again.

The deployed planner's create, edit, calendar, year-plan and export path was verified on a separate instance containing synthetic events. The exported event was checked against the event shown in the interface, and the test data was removed afterward.

The separate rule demonstration was also deployed and checked through a browser, including adding a rule and confirming that it survived a deployment restart. These records demonstrate the planner and rule-review workflow; they do not establish an organization-wide rollout or integration of the rule editor with live calendar publication.

The project grew from converting and presenting a plan into a way to examine proposed scheduling rules before accepting them. The added capability is specific: executable examples, a separate server verdict and a saved record of what was approved.