Docs & technical writing
AuraScore 81/100

High-Frequency Trading Runbook Standardization Plan

Plan the overhaul and verification of mission-critical incident response and failover runbooks for electronic trading platforms.

Use this template to plan the restructuring of mission-critical trading infrastructure runbooks. It sets up actionable schedules for documenting disaster recovery workflows, technical escalation paths, and exchange reconnection procedures.

Template

Role: Senior Trading Infrastructure Technical Writer specializing in low-latency systems and operational resilience.

Context

  • Brokerage / Trading Firm: {{brokerage_name}}
  • Trading Infrastructure Scope: {{trading_system_scope}}
  • Incident Severity Tiers: {{incident_severity_tiers}}
  • Governance & Regulatory Mandate: {{primary_audit_mandate}}
  • Documentation Repository & Toolchain: {{documentation_toolchain}}
  • Delivery Window: {{execution_window}}

Task

Construct a comprehensive project plan to rewrite, test, and validate mission-critical incident response and failover runbooks for {{brokerage_name}}'s {{trading_system_scope}}, ensuring alignment with {{primary_audit_mandate}} within {{execution_window}}.

Method

  1. Inventory existing emergency procedure documentation across {{trading_system_scope}}, identifying outdated diagrams, broken command scripts, and missing network failover paths.
  2. Standardize a uniform runbook template tailored for high-pressure incident mitigation (symptoms, immediate triage commands, verification commands, and rollback actions).
  3. Map procedural workflows to specific severity definitions outlined in {{incident_severity_tiers}}.
  4. Coordinate technical interview sprints with Site Reliability Engineers, quantitative infrastructure leads, and network engineers to capture failover sequences.
  5. Implement a strict validation mechanism within {{documentation_toolchain}} to test executable code blocks, CLI snippets, and monitoring query links.
  6. Schedule table-top disaster recovery drills to evaluate the accuracy and execution speed of the newly drafted runbooks.
  7. Prepare final regulatory artifacts demonstrating procedural resilience for {{primary_audit_mandate}} review.

Constraints

  • MUST format all diagnostic and remediation steps into sequential, deterministic command-line actions.
  • MUST NOT use ambiguous subjective language (e.g., 'wait a while' or 'check if healthy') without exact timeout values and metric thresholds.
  • All runbooks must include rollback procedures for failed manual interventions.
  • The execution roadmap must accommodate engineer shift schedules across trading desk operational hours.

Output format

Provide a technical runbook overhaul plan formatted under the following headings:

  1. Infrastructure Scope & Runbook Inventory (summary table)
  2. Standardized Runbook Structural Specification (anatomy of a production runbook)
  3. Authoring, Verification & Table-Top Drill Schedule (weekly progression across {{execution_window}})
  4. Tooling, Automated Linting & Version Control Plan (integration with {{documentation_toolchain}})
  5. Audit Compliance & Operational Sign-off Protocol (alignment with {{primary_audit_mandate}})

Self-review

  • Does the plan account for all system components listed in {{trading_system_scope}}?
  • Are command verification steps integrated into the authoring workflow to prevent stale instructions?
  • Is the validation methodology capable of satisfying {{primary_audit_mandate}} without disrupting trading hours?
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

writing-content
writing-docs
financial-services
runbooks
trading infrastructure
disaster recovery