# Detection-aware methods: an alternative methodology (user opt-in)

> **Up front**: this appendix is *not* the main workflow. The main workflow in `SKILL.md` — pattern catalog, voice profile, specificity, fact-check, soul — is built around writing *quality*. The goal is better prose, not lower detector scores.
>
> This appendix documents an **alternative methodology** whose purpose is different: it borrows methods from AI-detection-evasion tools to lower the probability that a draft is classified as AI-generated by automated detectors. The two methodologies are not interchangeable. They have different purposes, different risk profiles, and different audiences.
>
> **This skill does not recommend, default to, or actively promote this appendix.** It is documented for reference, for users who have made an informed choice, and for projects whose requirements differ from this skill's main stance. If you use it, you take responsibility for the outcome. The non-goals in `SKILL.md` still apply to the main workflow.

## Why this appendix exists

Two reasons.

1. **Reference completeness.** Readers who are evaluating writing tools will compare this skill to others in the same space. Several of those tools (notably [lynote-ai/humanize-text](https://github.com/lynote-ai/humanize-text)) are built around detection-evasion pipelines. Documenting those pipelines — what they do, how they work, what they cost — gives the reader a fair basis for comparison, without pretending the methods do not exist.
2. **A legitimate, narrow use case.** There are writing surfaces — public marketing copy, opinion newsletters, casual blog posts, internal documentation — where the author *is* the human and *is* using an LLM as a drafting aid, and where the author's concern is that automated detectors will misclassify a draft they actually wrote or that they have edited. For these surfaces, the alternative methodology has real value, and the main workflow's quality direction does not address the concern. The appendix gives the author a documented path.

The skill's main workflow remains the recommendation. The appendix is a documented choice for users who have decided they need a different tool.

## What the appendix describes

Four methodologies from the detection-evasion literature, plus the v1.5 "Standard Pipeline" that combines two of them. The descriptions are honest about what each method does and what it costs. None of them are magic; none of them are guaranteed.

### Method 1: Translation Chain

- **What it does**: routes text through two or more translation hops, typically EN → 中文 → 日本語 → Suomi → EN (or a similar distant-language chain), to disrupt the structural fingerprint of the source LLM.
- **Why it works (when it does)**: each translation hop introduces structural changes that the source LLM's statistical signature does not anticipate. Cross-language gaps (e.g. Chinese and Finnish) maximize the disruption.
- **What it costs**:
  - *Style loss*. The author's voice is partially flattened by each hop. The final English often reads as translated, not as native.
  - *Meaning drift*. Numbers, names, idioms, and nuance can shift. The longer the chain, the larger the drift.
  - *Engine fingerprinting*. The output now carries a translation-engine fingerprint (Google, DeepL, Niutrans) that a determined detector can sometimes identify.
  - *No fact guarantee*. Translation chains preserve the *form* of a claim, not its *truth*. An invented statistic in the input is still an invented statistic in the output.
- **Honest assessment**: useful when style preservation is not a priority and the author is willing to fact-check the result by hand.

### Method 2: Multi-turn LLM Rewriting

- **What it does**: rephrases the draft through two or more LLM rewrite passes (e.g. DeepSeek at temperature 1.3), with each pass carrying the previous one as conversation history.
- **Why it works (when it does)**: each pass has independent statistical variation. Carrying the previous pass as history keeps the rewriting coherent.
- **What it costs**:
  - *Voice loss*. Each LLM pass drifts toward LLM-default voice. The author's voice is gradually replaced.
  - *Tone drift toward LLM defaults*. Higher temperatures add creative variation but also randomness, including off-tone passages.
  - *No fact guarantee*. The LLM may "improve" the text by inventing specifics, adding confident claims, or removing hedges. Each pass multiplies the risk.
  - *Compute cost*. Two LLM rewrites plus two translation hops is meaningfully more expensive than a single semantic rewrite.
- **Honest assessment**: useful for short passages where the author is willing to lose voice for variation.

### Method 3: Detection-guided Feedback Loop

- **What it does**: runs the draft through one or more AI detectors (GPTZero, Originality.ai, etc.), reads the score, and revises the draft to lower it. The loop repeats until the score is acceptable.
- **Why it works (when it does)**: it is direct optimization against the detector's signal. If the score is the target, scoring against the target is the fastest way to hit it.
- **What it costs**:
  - *Detector drift*. Detectors update frequently. A score that is acceptable today may be unacceptable next month, with no change to the text.
  - *Adversarial coupling*. Optimizing against a specific detector's signal often produces text that has *that detector's* fingerprint (because the revisions cluster around what the detector responds to). A different detector may see the same text differently.
  - *Adversarial staleness*. The moment the technique is published, the detector can be updated to detect the technique's output. This is a moving target, not a stable improvement.
  - *Moral hazard*. The method is the canonical "AI detector bypass" technique, and using it explicitly to lower a detector score is the literal definition of detector evasion. It is not what the skill's main workflow is for.
- **Honest assessment**: the appendix documents this method for reference, because it is part of the published literature. The skill does not endorse it. The main workflow is the recommended path; this method is the most aggressive form of the alternative.

### Method 4: Mixed-engine Translation

- **What it does**: runs the translation chain through *different* translation engines at each hop (e.g. Google Translate for hop 3, Niutrans for hop 4) so no single engine's fingerprint dominates the output.
- **Why it works (when it does)**: cross-engine variation prevents the output from clustering around any one engine's structural defaults.
- **What it costs**:
  - *Setup cost*. Requires API keys for two or more engines. Configuration is non-trivial.
  - *Engine availability*. Some engines rate-limit free access. Quality varies by language pair.
  - *No fact guarantee*. Same as Method 1.
- **Honest assessment**: a useful enhancement to Method 1 when style is not the priority.

### Standard Pipeline (v1.5, the recommended combination in lynote-ai)

```
Input (EN) → Chinese (DeepSeek) → Japanese (DeepSeek) → Finnish (Google) → English (Niutrans)
```

This is Method 1 + Method 2 integrated: two LLM humanization rewrites (carrying history) followed by two cross-engine translation hops. It is the canonical "best of both worlds" pipeline from lynote-ai. It carries the costs of both methods: voice loss, style loss, meaning drift, compute cost, no fact guarantee.

## When this appendix is appropriate

Honest use cases — where the author is the human, the LLM is a drafting aid, and the author is editing the output:

- Public marketing copy where automated detectors are likely to misclassify and where the author has approved the substance.
- Opinion newsletters and casual blog posts where the author's voice is informal enough to absorb the style flattening.
- Internal documentation, where detectors are not actually a concern but the team standardizes on detection-aware pipelines for consistency.
- Translation tasks where the chain serves both humanization and language-conversion at once.
- Writing for a hostile or adversarial surface where the author has independently decided that lower detector scores are a legitimate priority.

## When this appendix is not appropriate

Use cases where the alternative methodology is the wrong tool:

- **Academic work, student essays, classroom assignments.** This is the canonical "AI detector bypass" use case the skill's main workflow refuses to serve. The skill's `SKILL.md` Non-goals and the Boundary in `README.md` apply. Use the main workflow, write the work yourself, or use AI for outline and explanation rather than drafting.
- **Authorship disclosure situations.** When a publication, employer, or platform requires disclosure of AI assistance, the alternative methodology does not change the disclosure obligation. The author still used AI.
- **Legal, medical, financial, or safety-critical writing.** The style and fact losses of the alternative methodology are unacceptable on high-stakes surfaces. Use the main workflow, fact-check, and have a human expert review.
- **Author-unaware situations.** The alternative methodology is not a tool for tricking a reader who was told the work was human-written. Honesty about AI assistance is a separate question that the methodology does not solve.
- **Automatic or default use.** The skill does not auto-invoke the alternative methodology. It is documented for the user who has chosen it.

## The reality of detection

The appendix would be incomplete without saying this out loud:

- **Detectors update frequently.** Any specific technique that lowers a score today will be less effective next month. No method in this appendix is a permanent solution.
- **Detectors disagree.** GPTZero, Originality.ai, Turnitin, Copyleaks, and the open-source detectors all use different signals. A draft optimized against one may score higher on another. The optimization target is moving and the optimization function is undefined.
- **Detectors are not the only reader.** A draft optimized for a detector may still read as AI to a human reviewer, and may read as AI to a future detector that the author has not tested against. The author is the long-term reader; the detector is a short-term gate.
- **There is no "passing" the detector.** There is "lowering the score" and "hoping the gate accepts it". The skill does not promise the second.

If the use case is genuinely "I need a lower detector score and I have decided the trade-offs are worth it", the appendix is a fair description of the available methods. If the use case is "I want a guarantee", the appendix cannot help. There is no guarantee.

## How this appendix relates to the main workflow

The two methodologies are **parallel, not replacement**.

- The main workflow (5-pass: pattern catalog → voice profile → specificity → fact-check → soul) is the recommended path. It produces text that is *better*. As a side effect, the same text is often harder for automated detectors to misclassify, because it carries fewer AI tells and more human voice. The skill does not promise or optimize for this side effect; it is observed, not targeted.
- The alternative methodology (this appendix) is the explicit path. It produces text that is *more likely to score lower on automated detectors*, at the cost of voice, style, and sometimes meaning. It is documented for the user who has chosen this path. It is not recommended for the user who has not.

A draft can be run through both. The main workflow first (to clean up the substance and the style), then the alternative methodology (if the user has decided the trade-off is worth it). The skill does not run the alternative methodology by default; the user opts in.

## A disclaimer template

If a user invokes the alternative methodology, the skill should produce a short disclaimer in the output, near the final text. The template:

```text
Note: this rewrite used the alternative methodology described in
docs/detection-aware-methods.md. The methods in that appendix
prioritize lower detector-classification scores at the cost of voice
preservation, style, and sometimes factual fidelity. The user is
responsible for the trade-off.

The rewrite is on the page below. The trade-off is in the box above.
```

Adjust the wording to the surface. The point is that the alternative methodology's costs are visible to the reader of the rewrite, not hidden.

## What this appendix is not

- It is not a recommendation. The main workflow is the recommendation.
- It is not a guarantee. None of the methods lower detector scores reliably over time.
- It is not the right tool for academic, student, or disclosure-bound work. The skill refuses those uses regardless of which methodology the user picks.
- It is not auto-invoked. The skill does not silently use these methods. The user opts in by reading this appendix and choosing the methods.
- It is not endorsed by the main workflow. The main workflow's quality direction is a separate stance.

The skill's boundary, in `SKILL.md` Non-goals and `README.md` Boundary, still holds. The appendix is a documented choice for users who have decided to step outside that boundary, with full information about what they are stepping into.