Rationarium Change Management Policy

Effective Date: January 1, 2026 Review Cycle: Annual Policy Owner: Chief Executive Officer / Chief Technology Officer, Rationarium Inc. Last Documented Review: December 9, 2025

Purpose

This policy describes how Rationarium Inc. plans, communicates, and executes changes to the production environments of institutional customers, and defines the customer’s role in authorizing and coordinating those changes.

Scope

This policy covers any change affecting the configuration, software, data, or availability of a customer’s Rationarium-hosted WeBWorK instance.

Change Categories

Standard changes — routine operational work that does not affect user-visible behavior or availability, pre-approved under this policy:

• Operating system security patches
• Backup and monitoring configuration updates
• Minor configuration changes with no customer impact

Significant changes — require advance customer coordination:

• WeBWorK major or minor version upgrades
• Underlying database or system software version upgrades
• Infrastructure migrations (region, provider, or instance resize)
• Changes to authentication, LTI, or LMS integration
• Changes to backup retention, data residency, or security posture

Emergency changes — applied immediately to mitigate an active incident:

• Security vulnerability remediation
• Outage response
• Abuse or service-degradation mitigation

Standard Change Process

1. Change is planned and prioritized by Rationarium engineering.
2. Change is scheduled during a low-usage window for the affected customer, typically overnight in the customer’s local time or during academic breaks.
3. A backup snapshot is captured before the change.
4. The change is applied.
5. Post-change verification is performed against health checks and synthetic probes.
6. The change is recorded in the Rationarium change log.

Customers are not individually notified of standard changes unless a change has user-visible effect.

Significant Change Process

1. Rationarium proposes the change to the customer administrator(s), including scope, rationale, expected user impact, and a proposed maintenance window.
2. The customer authorizes the change in writing (email is sufficient).
3. The change is scheduled with at least seven (7) days notice wherever practical.
4. A backup snapshot is captured before the change.
5. The change is applied during the approved window.
6. Post-change verification is performed with the customer administrator.
7. The change is recorded and customer confirmation is archived.

Institutional customers are notified in advance of any significant change that could affect their security posture, authentication, data handling, or availability.

Emergency Change Process

1. The incident is declared and handled under the Incident Notification Policy.
2. The customer is notified as soon as practical — before action where possible, concurrent with action where not.
3. A backup snapshot is captured if time permits.
4. The change is applied to contain or remediate the incident.
5. The customer is notified of completion.
6. A post-incident review is conducted within five business days, including root-cause analysis and any follow-up changes.

Communication

• Significant changes. Direct email to the customer administrator with at least seven days notice where practical.
• Emergency changes. Immediate notification through whichever channel reaches the customer fastest.
• Standard changes. Logged but not individually communicated.
• Status page. Changes that affect availability during the window are posted to https://status.rationarium.org.

Roles and Responsibilities

Rationarium’s current operating scale consolidates change approval and execution in the CEO/CTO role. As the organization grows, these functions will be separated and a formal change advisory board will be established.

Policy Review

This policy is reviewed annually and updated as operational practices evolve.