Published Service Scope
Explain which functions are supported, monitored, and considered essential.
Repository Service Levels, Maintenance & Incident Communication Policy
Keep the repository dependable. Communicate clearly when service changes.
The JR Institute intends to operate its future repository with defined service expectations, planned maintenance procedures, incident priorities, timely public updates, and continuity measures for extended disruption.
Developing Framework
This page presents a planned public standard. Final availability objectives, maintenance windows, incident severity levels, communication channels, recovery targets, and support responsibilities should be approved before repository launch.
Policy Purpose
Reliability includes honest communication, not merely technical uptime.
Authors and readers need to know when submissions, identifiers, downloads, moderation, search, or public records are unavailable or operating in a degraded state.
The Institute should communicate material disruptions without exposing security-sensitive details or making promises that cannot be supported.
Core Principles
Defined expectations, planned maintenance, prioritized recovery, timely notice, and accountable follow-up.
Planned Maintenance
Schedule disruptive work, give advance notice, and identify expected impact.
Incident Prioritization
Restore safety, record integrity, identifiers, access, and submissions in a defined order.
Public Status Updates
Communicate material outages, degraded service, recovery progress, and restoration.
Deadline Protection
Adjust repository-controlled deadlines when service disruption prevents timely action.
Post-Incident Learning
Document causes, impact, corrective action, and unresolved risks after major incidents.
Scope
This policy is intended to apply to repository browsing, search, downloads, identifiers, submissions, moderation tools, APIs, metadata feeds, authentication, preservation systems, administrative functions, and public incident communication.
Service Objectives and Supported Functions
The Institute should publish realistic service objectives for essential repository functions without presenting them as absolute guarantees.
Objectives may address public availability, identifier resolution, submission access, support response, backup completion, recovery, and preservation monitoring.
Planned Maintenance and Change Windows
Maintenance that may interrupt service should be scheduled during an appropriate window and announced with reasonable advance notice.
- Expected start and completion time
- Affected repository functions
- Expected user impact
- Alternative access or submission arrangements
- Update and restoration channels
Planned maintenance may still change when testing reveals added risk. Updated estimates should replace silent delay.
Incident Classification and Severity
Incidents should be classified according to impact on safety, confidentiality, scholarly-record integrity, availability, submissions, identifiers, preservation, and affected users.
Severity should guide escalation, staffing, communication frequency, executive notification, and external support.
Recovery Priorities
Recovery should ordinarily prioritize:
- Protection of people, sensitive information, and evidence
- Integrity of repository records and preservation copies
- Persistent identifier resolution and public record status
- Read access, search, and downloads
- Submission, moderation, and administrative workflows
- Nonessential analytics, enhancements, and convenience features
Status Notices and Incident Communication
Material disruptions should be communicated through a designated status channel separate from the affected service where practical.
Notices should identify affected functions, known impact, current mitigation, expected next update, and restoration status without revealing details that increase security risk.
Submission Deadlines, Moderation Queues, and User Protection
Repository-controlled deadlines should be extended or treated flexibly when a verified service interruption prevents submission, revision, response, appeal, or required access.
Queue order and timestamps should be preserved as fairly as practical after service restoration.
Extended Disruption and Continuity Operations
Extended outages may require read-only operation, alternate submission channels, static record mirrors, manual identifier support, reduced services, or transfer to temporary infrastructure.
Temporary continuity systems should preserve security, record integrity, timestamps, authorship, and later reconciliation with the primary repository.
Post-Incident Review and Corrective Action
Major incidents should receive a documented review of timeline, cause, impact, decisions, communication, recovery, evidence, control failures, and corrective action.
Public summaries should be released when they provide accountability without compromising security, privacy, legal obligations, or unresolved investigation.
Service Performance and Public Reporting
The Institute should report service availability, material outages, recovery performance, maintenance impact, unresolved risks, and major continuity improvements.
Metric definitions and exclusions should remain consistent enough for meaningful comparison over time.
Framework date: July 2026
Service Incident Lifecycle
Detect, classify, communicate, contain, recover, verify, and review.
- Detect and classify. Confirm the affected services, severity, users, records, and risks.
- Communicate. Publish an initial notice and define the next update time.
- Contain and recover. Protect data and restore essential services in priority order.
- Verify restoration. Test record integrity, identifiers, access, submissions, and monitoring.
- Review and improve. Document lessons, corrective action, unresolved risk, and public accountability.
Service or Incident Questions
Ask about maintenance, outages, degraded service, submissions, recovery, or incident reporting.
Inquiries may concern planned maintenance, unavailable records, identifier failures, submission interruptions, accessibility, restoration, status communication, or post-incident review.
Submit a Service Inquiry
Identify the affected function, date and time, observed behavior, record or account involved, urgency, and available technical details.
Contact the Institute