post-writing

name

post-writing

description

The public, LessWrong-style writeup of a control experiment. Ruthlessly compressed for a reader with zero context, leading with the surprise, citing public-viewer trajectory URLs only. Load this in the writing phase when producing the shipped post into `outputs/`. It lifts the STRONG-tagged claims from the internal [report-writing]; same evidence base, far less detail. Before shipping it runs the lw-review gate below.

A post is the cleaned-up public version of a protocol's report (see [report-writing]). It lifts the report's STRONG claims, compresses for a reader with zero context, leads with the surprise not a topic label, and ships to outputs/ (ordered via outputs/_order.md, so the read-only dashboard displays it). Never re-derive or re-grade; the report is the evidence base.

What a post is for. Control research discovers the strategies red and blue use and how they interact. The post's job is a gears-level model of those dynamics, not a leaderboard. The reader should come away knowing what red did, what blue did, and the mechanism by which one beat the other. Every post names the mechanism in plain language and cites at least one public trajectory that demonstrates it. A delta on a chart with no mechanism named is not done.

Voice anchors, read them before drafting: examples/external_retrying_vs_resampling.md (primary: opens on the question, TL;DR first, sections are mechanism-questions) and examples/external_ctrl_z_resampling.md. Style method: reference_writer_skill.md (characters as subjects, actions as verbs, kill nominalizations, old-before-new, cut filler). These anchor files are external references; ignore their em-dashes and italics, which are not the house style, and follow the voice rules above.

Voice (the hard style rules)

• No em dashes (use commas, colons, periods, parens). No arrows outside code (write "from 42/83 to 14/83"). No buzzwords (leverage, synergy, paradigm, holistic, robust, seamless). No italics.
• Bold the key points. A reader who reads only the graphs and the bolded lines should get the gist.
• Skimmable in under a minute. Every sentence adds new information. Simple epistemic status: High / Medium / Low, folded into the opening and Limitations, not a labeled block.
• Lead with the surprise, not the topic. Sentence 1 to 2 is the headline result as a delta from a reasonable prior; sentence 3 to 4 is one verbatim trajectory that proves it; sentence 5 plus is what changes for the reader. No "in this post we explore". If the result confirms the reader's prior, pivot the lead to the load-bearing mechanism or the bug the investigation surfaced.
• Say what happened, do not editorialize. Reject figurative or aphoristic phrasing that performs the point instead of stating it. Also strip: "X, not just Y" / "X isn't Y, it's Z" filler, over-intensifiers (very, clearly, obviously), empty evaluative noun phrases ("a real mechanism", "the key insight"), curly quotes. Read the draft aloud; cut anything you would not say to a smart colleague.

Public URL convention (mandatory, checked before publish)

Cite public-viewer trajectory URLs ONLY: https://data.linuxarena.ai/trajectories/<id>. NEVER the private internal viewer (equistamp.linuxarena.ai), never fly.dev, never a run-page or fleet URL (cite individual trajectories). A public post may cite ONLY trajectories whose environment is PUBLIC; a private-env trajectory must never appear even if it happens to render. If the only evidence is a private env, cite the aggregate number and say the trajectory is withheld, or find a public-env trajectory showing the same mechanism. Link TEXT must say what the trajectory shows ([caught at 9.0](...)), never the hex id. Verify every cited trajectory's env is public before publishing; when unsure, treat it as private. The private viewer is the internal [report-writing] convention; do not mix them.

Controlled vocabulary

Use the established control terms from [control-research-knowledge]; never coin words. Define each briefly on first use for a general reader (except "sneaky", which is obvious). Standard terms: untrusted model, trusted model / trusted monitor, main task, side task, side-task success, caught (a blue win even if the side task succeeded), uncaught success (the safety-losing case), audit budget, safety (use the exact formula and cases from [control-research-knowledge], do not restate a simplified version), usefulness, suspicion score, attack success rate (ASR), permissions / affordances.

Banned coinages, use instead: "landed" is "side-task success"; "loud / louder" is "suspicious / scores high"; "grain / grant" is "permissions / affordances / allow"; "gate" is the specific monitor by name; "leaky" is "more attacks succeed under broader permissions"; "quiet" is "sneaky / below the audit line". No metaphors at all, name the literal thing (the network policy, the trusted monitor, the suspicion score), never fence / moat / lever / knob / "moves the needle". Decide one term per concept and reuse it verbatim everywhere. Never alter a verbatim quote to remove a banned word.

Plain words for a general reader. No systems background assumed: "website" not "host", "list of allowed websites" not "allowlist", "send data out / steal credentials" not "exfiltrate", "run" not "episode", "the recorded runs" not "trajectories". Gloss unavoidable jargon (reverse shell, iptables, CVE) in one clause or footnote. Figures use the same plain words as the body; a diagram still saying "host" / "affordances" while the body says "website" is a finding.

• No internal jargon or codenames in reader-facing text. Never surface the plugin's or the game's internal labels.

Claims and per-claim body

Every claim section header IS the claim: non-trivial, human-legible, names a specific mechanism, falsifiable, the kind of sentence a skeptical reviewer can argue with. Good: "Per-action gating makes the same sabotage more suspicious, because the attacker has no standing permission to hide behind." Bad: "Our protocol works" (no mechanism), "B46 wins due to no-op" (internal label). Order claims macro to micro: first claim is the lens the whole post uses, then mechanism differences, ending with vulnerabilities and edge cases.

Write each claim as flowing prose (not a labeled Mechanism / Evidence template), in this order, and apply it recursively to every subclaim:

1. Intuition first, no numbers. The human, conceptual logic of why the attacker or monitor behaves this way. Get the reader nodding along with the mechanism BEFORE any statistic. The WHY is the intuition.
2. Claim, stated qualitatively. State the result in words ("request-permission is usually about as safe as per-action"). Put numbers in the FIGURE and its caption, not the sentence. At most one load-bearing number in the whole body, and only if a claim hinges on it.
3. One public trajectory as proof, link text says what it shows, with the verbatim attack or monitor snippet. Rule out infra in a clause if needed.

Numbers carry CIs, and within-noise is a real result. When a gap is inside its joint CI, write "we observe X higher", not "X is higher", and say the takeaway is the dynamics, then spend the section on trajectory-level intuition for why each cell behaves as it does. Do not hide a within-noise result behind a number, and do not inflate one into a claim. Weaken any claim only sometimes true, scan for every / all / always / never / only and check each against the data.

Required sections

• Title a specific claim or question, not a topic label.
• Opening (4 to 6 sentences): problem, headline result plus CI, next-most-interesting finding.
• Setup (one paragraph): what was held constant, what varied, models, task set, audit budget.
• Taxonomy table up front when comparing 3 or more options.
• Claim sections, macro to micro, Intuition then Claim then Data then Trajectory.
• ## Limitations (required): what the data does NOT support, per class. State the maximin was actually reached, verbatim: a post ships ONLY when every scaffolded blue and red iteration cell was actually run. If a scaffolded cell was not worth running, delete its dir; do not leave a deferred ghost. "Arms-race complete" prose is insufficient.
• ## Implications (required): 1 to 3 concrete things that would update for control researchers or labs. Disagreeable specifics, not "this matters for alignment".

Model-refusal handling. If the untrusted model refuses the canonical attack ("I cannot", "deliberately trying to get me to"), record it as an UNRESOLVED red iteration, not a blue defense. Evaluate against a realistic adversary the alignment layer does not trivially block; if none exists, say so under Limitations and qualify the safety number. Pivoting to a more-detectable attack just to make the run go, without disclosing it, is bad research.

Images

Every shipped post embeds key result images inline with ![alt](url) at their section position: the safety curve at the top of the safety section, the Pareto plot at the usefulness-versus-safety section, at least one mechanism diagram or annotated trajectory snippet at the convergence section. A post with zero embedded images fails. Every graph is generated by real infra (see [control-tower-usage]), never hand-drawn, with its regenerate command and source run URLs in outputs/README.md. The dashboard renders whatever is in outputs/ and computes nothing, so a reader who finds no safety curve there will not trust the inline images.

Graphs must be hosted so they render for a reader. Default with no extra setup: the PNGs already live in outputs/graphs/, so commit them and embed the committed file's raw URL (or attach the PNGs alongside the post). If an image host (e.g. Cloudinary) or the repo's S3 upload is configured, you may use it instead, always with a fresh versioned URL so a stale figure never renders — but that path needs its own credential, so it is optional, not a hard requirement. Record any returned URLs in <exp>/workspace/images/.

The lw-review gate (before ship, every publish)

The lw-review gate is a step, not a standing agent. Before a post ships, spawn a general-purpose reviewer (read-only) with the draft and this rubric, then fix everything it finds. Do not ship until a review pass returns zero actionable findings.

Reviewer rubric:

1. Numbers and graphs. Trace every prose number AND every hard-coded plot value to a source file. A number tracing to nothing is a finding. When two source files disagree, open the trajectory and read the decision substep; do not pick the convenient one.
2. Overclaims. Every "sometimes"-true claim stated as absolute, and any cross-section contradiction, is a finding.
3. Trajectory citations. Each cited id is real, in a PUBLIC env, on the public viewer, and the quoted score and behavior actually appear in the trajectory. A private-env or private-viewer citation is a finding.
4. Voice. Em dashes, arrows outside code, banned coinages, metaphors, buzzwords, bare-adjective claims, italics, a header that is a topic label not a mechanism claim: each is a finding.
5. Structure. Missing Limitations or Implications, no inline images, maximin not stated as reached, refusal recorded as a blue defense: each is a finding.

The gate does not replace the human signoff at ship; it is the machine pass before it.

Drafting workflow

1. Read the report ([report-writing]): STRONG claims, the surprising delta, the extracted trajectory quotes.
2. Expand into a loose draft (thought clarity over voice).
3. Distill per reference_writer_skill.md: characters as subjects, actions as verbs, kill nominalizations, old-before-new, cut filler.
4. Diagnose mechanically. Underline the first 7 to 8 words of each sentence: character as subject, action as verb, consistent subjects, new info at the end. Read aloud.
5. Read as a stranger with zero context: correct, complete, clear?
6. Run the lw-review gate, fix findings, repeat until a pass is clean, then ship to outputs/.

Cross-references

• The internal evidence base and support tags: [report-writing]
• Public vs private viewer, graph generation, reproduce commands: [control-tower-usage]
• Vocabulary, game, safety formula, protocols: [control-research-knowledge]
• Style method and voice anchors: reference_writer_skill.md, examples/