objectivize — Reframe private drafts into public-facing documents
You are not running a sensitive-word replacement table. Each document "leaks" its internal framing in a different way—first sense the particular pattern of subjective leakage in this specific draft, then let the rewrite be isomorphic to that pattern. Form follows function.
The categories below are sparks, not a checklist: if something is missing, don't force it; if something extra appears, name it on the spot. Treat this document itself as a fluid guide, not a rigid template.
1. Sense first, then act (not optional)
Read through the entire piece, then answer three questions: Who is this written for? Whose standpoint is it coming from? What things are said that only an insider would say? Classify the leakage points in your own words. Common beams of light:
- Named insider roles—boss/manager/client/our side/their side… external readers don't need to know who that is.
- Second-person address—telling the reader "you should / you will / remember this" treats them as a teammate, giving it the flavor of a memo.
- Presenting conjecture as fact—speculating about someone's "hidden expectations / true motivations / loyalty" as if it were known.
- Breaking the fourth wall—self-references like "this document / this answer / our current session / recording transcript", exposing the production process.
- Insider jargon and factional affect—internal abbreviations, alignment tone, inside jokes.
- Meta-narrative about process—explaining how the piece was made (what tools were used, what meetings were held, what workflow).
The output is a leakage map specific to this particular document, not a generic set of rules. Draw a new one for the next piece.
2. Distinguish "leakage" from "evidence" (the heart of this skill)
The most common mistake in objectivization is to erase evidence as well or alter real data—that is not objectivity but distortion or even falsification. The criterion is simple: Is it an observed fact, or the writer's tone? Keep the fact; change the tone.
- Direct quotes = evidence, preserve (can be atttributed neutrally). The interviewee's original words "I would never touch that software" stay—they support the argument.
- First-person reframing = leakage, rewrite. "Don't give me pie-in-the-sky ideas" is speaking for someone → "solutions must be grounded in evidence".
- Real data is sacred—user comments, logs, statistics, original screenshots. Even if the data happens to contain the very word you are cleaning up, never change it: changing it would be tampering with evidence. (Real lesson: a user's negative review that contained the word "boss" had to stay exactly as written.)
3. Rewrite, don't delete
Change the frame, don't lose the content. "The boss's real intention"→"project intention": the stance is gone, the information remains. When you feel like deleting a sentence, first ask "what judgment or fact does it carry?", then preserve that part in a neutral voice.
4. Choose one unifying lens
First select an external viewpoint (who is this report pretending to be, and who is it written for?), assign each insider role a neutral title based on that viewpoint, then maintain it consistently throughout the entire piece.
- Don't use three different terms for the same person in one document (project side / demand side / decision maker)—readers will think they are three parties. Order: assign titles first → sweep through replacements → verify consistency last.
- The "internal monologue skeleton" of each section must also be re-boned: change chapter titles like "What he said / didn't say / why he said it" (a meeting-postmortem frame) into an "objective analysis" frame (decisions already made / blind spots and open issues / deep motivations and constraints). Let the structure be isomorphic to the object of analysis, not to the meeting itself.
5. Objectivity ≠ false confidence
Removing subjectivity does not mean flattening out "confidence level / limitations / open questions / inference layer / needs empirical validation". These honest labels are precisely markers of objectivity—keep them.
6. Discipline at scale (when processing a full set of documents)
- Term uniformity can be scripted, but each batch builds its own dictionary—first sense the set of insider role names in this batch, then write the replacements for this batch only; do not reuse a table from the previous project.
- After mechanical replacement, always check for side effects—replace longer strings before shorter ones, otherwise you get concatenation errors like "被已被" or "需求方需求方"; then grep for residuals and malformed strings.
- Framing, voice, and second-person address can only be handled sentence by sentence by a human—scripts cannot touch them.
- Downstream artifacts must be rebuilt—if the source changes, regenerate the rendered HTML/PDF/index/cover page; do not only modify the source.
Self-check: imagine the output being read by a stranger on a public platform
- Are there still words like "you / we / our side / boss" that pull the reader or insider into the text (excluding quotes)?
- Are speculations presented as facts? Is the production process exposed?
- Does the same role have the same title throughout the entire document?
- Are real data and direct quotes untouched?
- Are confidence levels and limitations still present?
If any check fails, go back to step 1—but remember: each document passes the check in its own way; don't turn this self-check list into yet another template.