There is a version of grammar assistance that is straightforward to build: a database of rules, a parser that applies them, and a flag when a rule is violated. This works well for a certain class of errors. Subject-verb disagreement. Comma in place of a period. Missing article before a noun that requires one. Rules that apply uniformly across almost all written contexts and almost all readers.
The problem is that most grammar rules are not like this. Most grammar rules have context dependencies that the rule alone cannot describe. Building a grammar tool that handles context is a substantially harder problem, and the solutions do not look like a bigger rule database. They look like something closer to an understanding of what the writer is trying to do.
Rules that are mostly rules
Some grammatical structures are close to universally correct or incorrect across professional writing contexts. Subject-verb agreement is one of them. In formal written English, a singular subject takes a singular verb form and a plural subject takes a plural verb form, regardless of what comes between them in the sentence. This is not context-sensitive in any meaningful way for most professional writing.
These are the cases where rule-based systems shine. The rule is clear. The violation is unambiguous. The correction is obvious. A grammar checker can apply the rule mechanically with high precision and high recall and create genuine value for the writer.
Article usage is almost in this category. The rules governing definite and indefinite articles are complex enough that edge cases exist, but the core pattern, "a" before non-specific singular countable nouns, "the" before specific or previously mentioned nouns, is consistent enough that rule violations are identifiable with high confidence in most contexts. The edge cases are mostly at the margins of literary or highly stylized writing, not in professional email and documents.
Rules that are mostly guidance
The more interesting cases are constructions that are "wrong" in some contexts and normal in others. The comma splice is a useful example. Joining two independent clauses with a comma instead of a period or conjunction is treated as an error in formal academic and business writing. In some literary traditions, in conversational registers, and in specific rhetorical contexts, it is a deliberate stylistic choice that achieves specific effects. "It was raining, we stayed inside" reads differently from "It was raining. We stayed inside." or "It was raining, so we stayed inside." The comma splice is not wrong; it is contextually appropriate or contextually inappropriate.
The split infinitive is a similar case, though it is even more context-sensitive. The traditional proscription against split infinitives ("to boldly go" should be "to go boldly") has been effectively abandoned in contemporary edited English. Most style guides now treat it as a non-issue or explicitly permit it when the alternative creates awkwardness or changes emphasis. A grammar tool that flags all split infinitives is applying a rule that most modern professional writers and editors no longer recognize.
Passive voice falls in this category too. Passive voice is appropriate in scientific writing when the process is more relevant than the agent. It is appropriate in certain kinds of formal communication where diffusing agency is communicatively useful. It is overused in bureaucratic writing where active voice would be clearer. Flagging all passive voice constructions produces too many false positives; ignoring passive voice misses a real stylistic issue in the contexts where it matters.
What context means in practice
For a grammar tool to handle context, it needs some way of knowing what kind of document it is looking at and what kind of writing norms apply to that document type. This is harder than it sounds. A writer composing text in Gmail could be writing a formal request to a client, a casual update to a colleague, or a job application. All three are email. All three have very different norms.
What we have found useful at Linguix is a combination of explicit signals, things the user tells us or that we can infer from the platform, and distributional signals, patterns in the text itself that correlate with particular writing contexts. An email that opens with "Dear Mr. [Name]" and includes formal salutation and closing language is likely operating in a different register context than one that opens with the recipient's first name and ends with "thx."
We use these signals to adjust the confidence thresholds and the categories of suggestions we surface. In a text we classify as formal professional communication, passive voice and nominalization are more worth flagging. In a text we classify as casual team communication, they are less worth flagging. This is not a perfect system, and we surface the wrong suggestion in context regularly enough that we are still actively improving this layer. But it is the right direction: teaching the system that context determines whether a construction is a problem, not just whether it matches or violates a rule.
The rule-plus-context model
Our current approach combines rule-based checking for the constructions that are rule-sensitive with model-based classification for the constructions that are context-sensitive. Rule-based checking handles the cases where context does not matter much and high precision is achievable. Model-based classification handles the cases where the appropriate response depends on what the text is trying to do.
This is not an either-or choice. Rules are valuable. A rule that catches subject-verb disagreement is more reliable than a model for that specific task, because the model will occasionally miss an obvious violation and occasionally flag an acceptable construction. Rules are brittle at the edges, but for core grammatical constructions with narrow context dependencies, they outperform models on precision.
The model component is valuable for the larger set of constructions where rules alone are insufficient: register-appropriate formality, style choices that are context-dependent, patterns that are associated with specific error types in specific writer populations. This is the work that cannot be done by looking at a single sentence in isolation.
What this means for writers
For the writer using a tool like Linguix, the practical implication is that grammar suggestions should be read as signals rather than verdicts. A flagged passive construction is worth examining in context. Maybe active voice is better here. Maybe passive voice is doing deliberate work. The suggestion should prompt the question, not answer it.
We try to make this explicit in how we surface suggestions: the explanation alongside the suggestion is more important than the suggestion itself, because it gives the writer the information to make their own decision. "This is passive voice" is less useful than "passive voice here obscures who is responsible for the action." The first is a rule application. The second is context-aware guidance.
Rules need more than rules because writing is communication, and communication involves meaning, context, and relationship. Getting grammar right is necessary but not sufficient for writing that works. The goal is not correct text but clear text in the right register for the situation the writer is actually in.