The runbook / Part 2

Part 2: Guarding the write boundary

Series index Part 2 of 4

This page is an editable draft outline. Its date is a proposed editorial date. Replace the prompts with reviewed essay text before marking it complete.

Intended argument

Define the write boundary as the point where a proposed action changes a file, system, or external record, and explain how permission is checked there.

Essay outline

Identify the mutation

Choose a concrete example, such as changing a repository file. Name the target, intended change, approving role, and execution tool.

Bind approval to the action

Describe how approval identifies the task, action, resource, and expiration. Explain what invalidates approval when the proposal changes.

Enforce the decision

Locate the check at the tool or service that performs the change. Describe the result when approval is absent, stale, or for a different target.

Record the outcome

Specify the evidence recorded after an attempted change and the response to an uncertain outcome.

Evidence to add

Use the following checklist while drafting:

  • Add one permitted action and one rejected action using the same example.
  • Document how permission is rechecked after a proposal changes.
  • Distinguish a reference policy from controls verified in a running system.

Accompanying artifacts

Use these reference files to copy or adapt the proposed controls:

Complete the essay

Complete these steps before marking the essay complete:

  1. Replace the outline with the essay and verify its claims and examples.
  2. Check the artifact links and remove information that is not intended for public access.
  3. Set the actual publication date and change draft: true to draft: false in the front matter.
  4. Review the change on develop, release it to main, and verify the rendered page. Dates in this series are editorial labels and do not delay the Pages build.

Return to the series overview.