Editing, in practice

A real, ongoing case study — not a sales page. This is the actual build behind Logic Remediation's editing service, told honestly, including what didn't work the first time.

Problem

Manuscript and business-document editing is judgment work: deciding what a claim actually depends on, whether two statements quietly contradict each other, whether a sentence's rhythm serves the reader. That kind of judgment doesn't reduce to a fixed checklist, but a fixed checklist is exactly what a spellchecker already does well and cheaply. The real design problem was figuring out which parts of an editing pass are genuinely which kind — before writing a line of code, not after.

Discovery

Some editing tasks are checkable by rule: is a word spelled correctly, is a sentence unusually long, does a quotation mark ever get left open. Those questions have one right answer, computable directly from the text — a deterministic system can answer them completely, cheaply, and the same way every time. Other tasks aren't like that at all: does this paragraph's claim actually follow from the one before it, does this passage's voice match the rest of the document, is this contradiction a real one or two different things that happen to share a word. Those require judgment a fixed rule can't fully capture.

Solution

The pipeline runs both, deliberately kept separate. Mechanical, deterministic scanners do the coverage work — every spelling error, every unusually long sentence, every passage that looks structurally redundant — cheaply and completely, with no judgment involved. Their output is never a verdict. It's handed, afterward, to a semantic AI pass that does the actual judgment work: deciding what's really wrong, what's a false alarm, and what the deterministic scan missed entirely because it isn't the kind of thing a fixed rule can see. The AI is the orchestrator sitting on top of a mechanical foundation, not a replacement for it — and it's never allowed to see the mechanical scan's output before forming its own independent read of the document, specifically so it can't be quietly capped by whatever the cheaper system already found.

Lesson

The instinct going in was to ask "can AI do this?" The better question turned out to be "does this specific task already have a reliable, deterministic way to answer it — and if it does, why pay a semantic system's cost and unpredictability to re-derive that answer instead of just computing it?" A semantic system earns its cost on the sliver of the problem that's genuinely a judgment call, not on the sliver a fixed rule already solves for free. Knowing which sliver is which, before building anything, is most of the actual engineering.