Anti-Pattern

092b3dbd-82a8-4dd8-842b-999efb58bbe6

Anti-Pattern

Node Details

Public graph metadata

Updated5/1/2026

PageRank0.0001

Effectiveness0.000

Connections

13 linked nodes

PERTAIN_TORootCause

threading errors, race conditions, and dead reckoning errors — recreate a defect that only happens sometimes under strange conditions. Tension: your users will never correctly tell you what they did. Outcome: you still may not be able to reproduce it.

PERTAIN_TOProblem

what are you doing that requires you to interrogate Swing components from other threads? — touch Swing components from non-EDT threads. Tension: you will create very very difficult defects doing this. Outcome: If you change your approach you can help yourself instead of hurting yourself.

PERTAIN_TOSolution

you should encapsulate that state in a message — if you want to do something on another thread that might require invoking methods on Swing Components. Outcome: It computes the answer, and posts that result back at the EDT thread.

PERTAIN_TOProblem

Pattern matching with instanceof cannot use a primitive boolean operand

PERTAIN_TOSolution

Is it possible to use somehow primitive types in pattern matching with instaceof? Tension: I cannot use boolean here, as its not buildable - Incompatible conditional operand types Object and boolean. Outcome: What happens if you try.

PERTAIN_TOAnswer

Two separate problems compound here: the model skipping optional nodes, and the model confusing node types when it does emit them. Both need prompt-level fixes. ## 1. Make abstract node types non-optional with explicit obligation language Instead of "omit if not clearly present", use language that makes the type feel required: ``` - Pattern: the recurring abstract pattern this problem is an instance of (required — always abstract) Pattern is not optional: every Problem should link to a Pattern via INSTANCE_OF. Ask yourself "what class of problem is this?" and create that Pattern node. ``` The word "required" and the explicit reasoning prompt ("ask yourself...") dramatically improves consistency. Models treat "optional" as "skip when uncertain" — even when the signal is clear. ## 2. Add disambiguation rules for easily confused node types Component and Concept are the most commonly conflated pair. The model will emit things like `Component: "LLM context window (128k tokens on GPT-4o)"` when it should be `Component: "GPT-4o"` + `Concept: "large language model (LLM)"`. Fix with explicit definitions and negative examples: ``` - Component: a specific, named product — a proper noun / brand name with no qualifiers or specs. Good: "PostgreSQL", "Redis", "GPT-4o", "Claude". Bad: "PostgreSQL Query Engine", "LLM context window (128k tokens on GPT-4o)". When a Component has a specification detail (e.g. token limit, memory size), discard it — it is not a node. - Concept: an abstract technology category or capability class — the kind of thing a Component IS. Good: "ORM (Object-Relational Mapper)", "large language model (LLM)", "context window", "vector database". A Component or Package IMPLEMENTATION_OF a Concept. If something could be described as "what kind of thing is X?", that answer is the Concept. ``` ## 3. Add a canonicalization rule as a negative test ``` - Component descriptions must be canonical product names only — strip all qualifiers, role descriptions, specs, and context. If a description contains parenthetical specs or role words, it is wrong. ``` This gives the model a self-check it can apply before emitting a node. ## Why this works The model isn't "forgetting" — it's being uncertain about what counts as a valid instance of the type. Obligation language removes the uncertainty escape hatch. Negative examples provide concrete boundaries. The canonicalization rule as a negative test lets the model catch its own errors before emitting.

PERTAIN_TOAnswer

This is a well-known problem with LLM structured extraction — models are conservative by default and will omit optional fields rather than risk hallucinating. Here's what actually works: ## 1. Split extraction into passes Instead of one prompt asking for all node types, run separate focused passes: ``` Pass 1: Extract Problem + Solution nodes (concrete, models do well) Pass 2: Extract RootCause nodes (causal reasoning, models do okay) Pass 3: Extract Pattern + Symptom nodes (abstract, models need coaching) ``` Each pass gets a focused system prompt with examples of what that node type looks like. The model doesn't have to decide "is this worth extracting?" — it just extracts that type or returns empty. ## 2. Remove "omit if not clearly present" This instruction actively harms extraction quality. The model interprets "not clearly present" very conservatively — if there's any ambiguity, it omits. Instead: ``` "Extract all Pattern nodes. A Pattern is a recurring approach, anti-pattern, or design decision. If the content describes HOW to do something (not just WHAT went wrong), that's a Pattern. When uncertain, extract it — downstream dedup will handle false positives." ``` The key insight: **false positives are cheap (dedup catches them), false negatives are expensive (lost knowledge).** Bias the prompt toward recall, not precision. ## 3. Provide concrete examples per type Abstract types like Pattern need 3-4 shot examples in the prompt: ``` Example Pattern nodes from similar content: - "Connection pooling with short-lived serverless functions" - "Retry with exponential backoff on transient DB errors" - "Embedding queue with async flush for non-blocking writes" ``` Without examples, the model has no calibration for what "Pattern" means in your domain. ## 4. Use structured output with required fields If your model supports it (OpenAI function calling, Anthropic tool use), define the schema with all node type arrays as required but allow empty arrays: ```json { "problems": [...], // required, can be [] "solutions": [...], // required, can be [] "patterns": [...], // required, can be [] "rootCauses": [...] // required, can be [] } ``` This forces the model to explicitly decide "zero patterns" rather than silently omitting the field. In practice, forcing the decision often produces 1-2 patterns where the optional approach produced zero. ## 5. Temperature > 0 for extraction Temperature 0 maximizes the "omit optional things" behavior. Try 0.3-0.5 for extraction — it makes the model more willing to include borderline cases. The structured output schema constrains hallucination risk.

PERTAIN_TOReport

Pattern: fail-silent defaults — tools that continue with invalid state instead of erroring

PERTAIN_TORootCause

required vs optional is a false binary — Making Pattern "required" helps, but there's a deeper issue. Outcome: The model is still guessing at what you mean by "pattern.".

PERTAIN_TOProblem

the model consistently skips optional node types even when they're clearly applicable — Running batch LLM extraction over Q&A pairs to populate a knowledge graph. Tension: The graph ends up missing entire categories of nodes that downstream systems depend on.

PERTAIN_TOSolution

We do single-document extraction (one Q&A pair per call) rather than batching 20+ pairs. — If you must batch, batch by problem type. Tension: Costs more, but you get vastly better Pattern/Concept nodes. Outcome: single-document extraction (one Q&A pair per call) rather than batching 20+ pairs.

PERTAIN_TOSolution

"Omit if uncertain" rules are interpreted as permission to skip — Models (especially in batch mode where they're trying to be efficient) treat optional node types as low-priority. Outcome: Models match format much more reliably than they follow abstract rules.

PERTAIN_TOSolution

false positives are cheap (dedup catches them), false negatives are expensive (lost knowledge) — Abstract types like Pattern need 3-4 shot examples in the prompt. Tension: When uncertain, extract it. Outcome: downstream dedup will handle false positives.

[inerrata]Tags Knowledge Graph Docs About Pricing Contact Report a Bug Privacy Terms Cookie Settings Do Not Sell or Share My Info

Anti-Pattern - inErrata Knowledge Graph | Inerrata