check-terminology-infoflow

name

check-terminology-infoflow

description

Check terminology, invented jargon, concept consistency, information flow, and cross-paper factual consistency in LaTeX papers. Use for undefined or drifting terms, difficult paragraph flow, architecture or workflow contradictions, claim/number drift, figure/table mismatches, interface-versus-mechanism conflicts, and paper-versus-artifact inconsistencies. Supports terminology-infoflow, paper-consistency, and combined review scopes.

Terminology, Information Flow, And Paper Consistency

Check the LaTeX file at $ARGUMENTS for terminology consistency, invented jargon, concept coherence, information flow, and paper-wide factual consistency. If no argument is given, ask which file to check.

Do not perform any Git operation. Return findings and permitted paper changes to the caller.

This skill catches deep readability and consistency problems that sentence-level style checking misses. The root cause of "reads hard" is usually not punctuation but: (a) the reader encounters a term they do not know, (b) the same idea uses different words in different places, (c) a paragraph repeats what an earlier section already said, (d) the logical thread breaks, or (e) the paper presents conflicting mechanisms, claims, numbers, figures, interfaces, or workflows.

Scope Selection

• Terminology-infoflow scope: Run the Jargon (J), Consistency (C), Information Flow (F), and Cross-Section Coherence (X) checks in this file. Use for readability, terminology, concept ordering, paragraph flow, and reader-facing coherence.
• Paper-consistency scope: Read references/paper-consistency.md completely and follow its diagnostic contract. Use for architecture, interface/mechanism, workflow, claim, number, figure/table/listing, artifact, notation, or sibling-document consistency.
• Combined scope: Run paper-consistency first to establish factual anchors, then run terminology-infoflow. Deduplicate findings and never let a readability edit override an authoritative mechanism, artifact, or admitted result.

Paper-consistency scope is diagnostic by default. Report conflicts and minimal fixes; edit only when the user or a parent workflow explicitly requests fixes. Terminology-infoflow scope applies targeted fixes by default unless invoked as a read-only review subagent.

Process

1. Read the entire file
2. Build a concept inventory: list every technical term, its definition location, and all use locations
3. Run checks in order: Jargon (J) → Consistency (C) → Information Flow (F) → Cross-section (X)
4. Report issues grouped by severity: Must fix (reader cannot understand), Should fix (reader confused or slowed), Consider (polish)
5. In terminology-infoflow scope, apply fixes directly—Must fix first, then Should fix, then evaluate each Consider. Do not ask the user and do not silently discard Should-fix items. When invoked read-only as a review subagent, report only. In paper-consistency scope, follow the reference's diagnostic output unless fixes were explicitly requested.

Editing discipline

• Minimal targeted changes only. Never rewrite, restructure, or delete existing content unless explicitly asked.
• NEVER delete design decisions or technical content.
• NEVER change the meaning of a sentence. If unsure, flag instead of editing.
• System name via \sys macro only. Flag hardcoded system name as Must-fix.
• Verify before claiming done — recompile LaTeX, check it builds.

---

J: Jargon & Invented Terms (check FIRST — highest impact)

Invented jargon is the single biggest cause of "reads hard." AI-drafted and project-internal prose coins compound nouns that look professional but no reviewer recognizes.

J0: Term frequency audit (run FIRST)

Before checking individual terms, scan the paper's vocabulary to find the problem terms.

# Count all compound terms (hyphenated)
grep -v '^%' file.tex | grep -oE '[a-z]+-[a-z]+' | sort | uniq -c | sort -rn | head -30

# Count high-frequency single words
grep -v '^%' file.tex | tr ' ' '\n' | grep -oE '[a-z]{5,}' | sort | uniq -c | sort -rn | head -30

Long-tail terms are the biggest reader burden. A compound term used 1-2 times costs the reader effort to parse and remember but never becomes familiar. Apply these rules:

Frequency	Action
1 time	Almost always inline as plain language. If you need a concept once, describe it, don't name it.
2-3 times	Justify its existence. Can you replace with a high-frequency synonym or inline it? If not, define at first use.
4+ times	Earns its keep as a term — but still must pass J1 (reviewer test).

The goal is fewer terms, not more definitions. When you find a low-frequency compound, the fix is usually to delete the compound and use plain words, not to add a definition. "mapping-derived labels" (4×) → "mapped labels" or just "labels" when the context is clear. "oracle-rich families" (3×) → "families with ground-truth annotations". "system-effect weight" (7×) → "system weight" after the concept is established.

High-frequency terms that are too long should also be flagged. If a 3+ word compound appears 10+ times (e.g., "fixed-session drilldown" 11×), consider whether a shorter synonym works in some positions ("per-session view", "session drilldown").

Core concept budget. A paper should introduce a small, fixed number of named concepts — terms that the paper coins or redefines and expects the reader to learn and remember. Everything else should be either a standard community term or plain language.

Paper length	Core concept budget
Workshop (6-7 pages)	3-5 named concepts
Full paper (12-14 pages)	5-8 named concepts

To check: list every \emph{} or bold-introduced term that is NOT a standard community term. If the count exceeds the budget, the paper is overloading the reader. For each term over budget, ask: can this be expressed as plain language, or folded into an existing core concept?

What counts as a core concept:

• A term the paper formally introduces with a definition and uses 5+ times
• The term enables the reader to talk about the paper's contribution concisely
• Removing it would force awkward circumlocutions

What does NOT count:

• Standard community terms (flame graph, call stack, span tree, eBPF) — no budget cost
• A compound used 1-3 times — inline as plain language, don't name it
• An implementation detail (regex rules, LLM tagger, K-Means) — describe, don't coin
• A metric name (mixed-weight percentage, V-measure) — define when used, don't treat as a core concept

J1: The reviewer test (P0)

For every compound technical noun (2+ words used as a term of art), ask: "Would a reviewer at this venue recognize this term without our paper defining it?"

• YES → keep (e.g., "flame graph", "span tree", "call stack")
• NO, but this paper formally introduces it → keep if defined at first use with motivation
• NO, and it just appeared → Must fix. Replace with plain language or the field's standard term.

Grep for candidates:

# Find capitalized or hyphenated compound nouns that might be invented
grep -onE '[A-Z][a-z]+-[A-Z][a-z]+|[a-z]+-[a-z]+ [a-z]+' file.tex | sort -u

Red flags:

• Compound appears exactly once with no definition
• Term cannot be found in the paper's own related work or cited papers
• Reader would ask "X 是啥?" and author needs >1 sentence to explain
• Term is a workflow/project artifact name leaking into prose (run IDs, script names, internal metric names)

Common AI-drafting inventions to watch for:

• *-aware compounds ("query-aware", "label-aware") — OK if defined; flag if used without definition
• *-level qualifiers — often redundant (see J2)
• *-derived / *-based chains — check if the base concept is defined
• Internal process vocabulary: "artifact ledger", "run ledger", "source-status", "hygiene check", "gate", "reviewer packet"

J2: Redundant qualifiers

Often redundant	Usually needed
system-level (just "system")	OS-level (vs tool-level)
kernel-level (just "kernel")	intent-level (vs syscall-level)
execution-level (just "execution")	category-level (vs span-level)

Test: does removing -level / -based / -driven lose meaning? If not, drop it.

J3: Project vocabulary leaking into paper prose (P0)

Paper prose must not read like a project report, README, or experiment log. Check for:

• Run IDs, script names, output paths ("R320", "run_rq2.sh")
• Internal metric names not defined in the paper ("prevalence/group-size null")
• Tool-specific configuration vocabulary ("profile-spec patches", "rank-feature rows", "guided repairs")
• Evaluation-internal shorthand never explained to the reader ("label-drilldown", "boundary-derived fields", "visible-risk ranker")
• Status-update language ("we then ran...", "the next step was...")
• Implementation-detail nouns used as concepts ("profile spec", "mapping rule") without explaining what they mean to a reader who has not seen the codebase

Test: could you submit this sentence to a reviewer who has never seen your repo? If they'd need access to your codebase to understand it, rewrite.

Especially in evaluation sections: every metric name, baseline name, policy name, and configuration shorthand that appears in a table or prose must be either (a) a term the community already uses, or (b) defined in the paper before first use. If a table says "op-stack:query-aware" and the body says "operation-stack query-aware profiling", the reader must not have to guess these are the same thing.

J4: Section and RQ titles must use reader language (P0)

Section titles, subsection titles, and research-question names are the first thing a reviewer reads. They must use the reader's vocabulary, not internal methodology terms.

Check: for each \section and \subsection title, ask: "Would a reviewer who has not read the paper body understand what this section is about from the title alone?"

Common violations:

• RQ title describes the evaluation method instead of the question the reader cares about ("Can X Localize Hidden Labeled Problems?" → the reader cares "Does X Find Real Problems?", not about your hidden-label methodology)
• Title uses paper-internal compound nouns ("flat views", "mixed-intent buckets", "derived labels") that the reader has not seen defined yet
• Title uses nested relative clauses that are hard to parse ("Does X Separate What Y Mix?" — three concepts in one clause)

Fix: rewrite the title to state the question in plain language that any reviewer at the target venue would understand without reading the body. The methodology belongs in the body text, not the title.

Bad: RQ2: Can Profiler Groups Localize Hidden Labeled Problems? Good: RQ2: Does Profiler Output Correspond to Real Problems?

J5: Term overloading (same word, two meanings) (P0)

If the same word is used for two distinct concepts, the reader cannot tell which meaning is intended.

Check: for each high-frequency term, list all the meanings it carries. If >1, either rename one or add a qualifying adjective at every use.

Common overloads to watch for:

• "label" = semantic tag assigned by intent recognition AND ground-truth annotation from a benchmark
• "stack" = operation stack (this paper's abstraction) AND call stack (CPU profiling concept)
• "view" = the formal triple $(\varphi, \sigma, w)$ AND a loose synonym for "perspective"
• "operation" = the record type AND a loose synonym for "action"

Fix: add a qualifier ("semantic label" vs "ground-truth label", "operation stack" vs "call stack") or pick different words for different concepts.

J6: Audience calibration

Terms that are standard at one venue may need definition at another. Before reviewing, identify the target venue and its community.

Check: for each technical term from a neighboring field, ask "would a typical reviewer at this venue know this term?" If uncertain, add a one-clause definition at first use.

Examples:

• OS venue readers may not know "span tree", "LLM call", "token budget" without brief explanation
• ML venue readers may not know "eBPF", "uprobe", "call stack" without context
• Workshop papers have a broader audience range than main conferences

---

C: Consistency (same concept → same term)

C1: Synonym drift (P0)

Grep for near-synonyms of every key concept. If the same concept uses multiple terms, unify to one.

# Example: check if "label" and "tag" are used interchangeably
grep -onE '\b(label|tag|annotation|marker)\b' file.tex | sort | uniq -c

Common drift pairs to check (adapt to paper's domain):

• label / tag / annotation / marker
• policy / rule / constraint / directive
• view / projection / aggregation / summary
• record / entry / event / sample / operation
• harness / runtime / framework / system
• merge / fold / aggregate / combine / collapse

For each pair found: are they genuinely distinct concepts? If yes, ensure the distinction is stated. If no, pick one and replace all instances of the other.

C2: Defined-before-used (P0)

Every technical term, acronym, and notation must be defined before first use, including in:

• Abstract (readers start here)
• Figure/table captions (readers hit these out of order)
• Section headers

Check method: for each technical term, find (a) definition location and (b) first use location. If (b) < (a), it's a Must-fix.

C3: Compound adjective hyphenation

Compound adjectives before nouns need hyphens; standalone uses do not.

Before noun (hyphenate)	After verb (no hyphen)
cross-session aggregation	aggregate across sessions
query-time projection	chosen at query time
single-run debugging	debug a single run
intent-derived labels	labels derived from intent

grep -onE '(cross|query|single|intent|system|per|multi)[- ](session|time|run|derived|effect|layer|view)' file.tex | sort | uniq -c

C4: Spelling variants

Pick one and enforce consistency:

• runtime vs run-time
• predefined vs pre-defined
• subagent vs sub-agent
• dataset vs data set
• backend vs back-end

C5: Capitalization

Check proper nouns and acronyms for consistency:

grep -oE '(eBPF|EBPF|ebpf|GitHub|Github|macOS|MacOS)' file.tex | sort | uniq -c

C6: Notation and symbol consistency

Math symbols and formal notation must be used identically wherever they appear. If $\varphi$ is defined as a predicate in §3, do not switch to the word "predicate" without the symbol elsewhere, or use a different symbol for the same concept.

Check: list every math symbol defined in the paper. For each, grep for (a) the symbol and (b) its plain-text synonym. If the paper alternates between symbol and text for the same concept, unify.

grep -n 'varphi\|predicate\|filter' file.tex | head -20

C7: Figure/table caption terms match body text

Readers often read captions before body text. If a caption uses a different term or abbreviation than the body, the reader must guess whether they mean the same thing.

Check: for each figure/table, compare the terms in the caption with the terms used in the paragraph that references it.

Common mismatches:

• Caption says "Mixed wt.%" but body says "mixed-intent weight percentage"
• Caption says "R@5" but body says "top-five recall" with no definition of the abbreviation
• Caption uses a short form ("op-stack") that body never introduces

Fix: either define the short form in the caption ("op-stack = operation-stack") or use the full term.

---

F: Information Flow (within paragraphs)

F1: Topic sentence test

The first sentence of every paragraph should state the paragraph's main claim or topic. If the first sentence is an example, definition, or subsidiary detail, the paragraph lacks a topic sentence.

Check: read only the first sentence of each paragraph in sequence. Do they tell the paper's story? If not, the topic sentences are missing or misplaced.

F2: Old → new thread (Gopen & Swan)

Each sentence should begin with something the reader already knows (backward link) and end with the new information (stress position).

Bad: A 40% reduction in latency results from label caching.

• "A 40% reduction" is new — reader doesn't know what to anchor it to Good: Label caching reduces latency by 40%.
• "Label caching" is known; "40%" is the new, stressed information

Systematic check: for each sentence, is the subject something mentioned in the previous sentence or established context? If the sentence introduces a completely new subject with no backward link, it breaks the thread.

F3: Why before what

Every design decision must state its motivation before the mechanism. If a sentence describes what the system does without first saying why, the reader lacks context.

Pattern: "Because [problem/need], [mechanism]." or "[Problem]. [Mechanism] solves this by [how]."

Bad: \sys uses a single abstraction. (what, no why) Good: Because agent activities span both layers, \sys uses a single abstraction. (why, then what)

F4: Claim before evidence

In evaluation paragraphs, state what the numbers mean before giving the numbers. The reader should know why the data matters before seeing the data.

Bad: 217 (36%) have one clause. 231 (38%) have two. (data dump) Good: Most policies are structurally simple: 74% have at most two clauses. (claim, then evidence)

F5: One idea per paragraph

Each paragraph should contain exactly one main point. If a paragraph covers two unrelated ideas, split it. If the same idea spans two paragraphs without a clear progression, merge.

F6: Logical connectors between sentences

Sentences within a paragraph must signal their logical relationship (contrast, consequence, elaboration, addition). Bare juxtaposition forces the reader to guess the connection.

Check: read consecutive sentence pairs. Is the relationship explicit ("because", "however", "therefore", ", so", ", and") or left implicit? Two implicit transitions in a row is a Should-fix.

F7: Example before abstraction (concrete before abstract)

Show a concrete scenario before the abstract generalization, so the reader has an anchor. "Once the reader has the intuition, they can follow the details." (SPJ)

Bad: An operation stack is an ordered list of fields. For example, [session, prompt_tag, kind] produces... Good: A developer asking 'which task categories consume the most tokens?' needs session, prompt_tag, and kind as the grouping axes. An operation stack formalizes this as an ordered field list.

F8: Concept dependency order

Concepts should be introduced in dependency order: if understanding B requires A, define A first. This goes beyond C2 (defined-before-used for terms) — it applies to the conceptual building blocks.

Check: draw the dependency graph of the paper's key concepts. Is the prose order a topological sort of this graph? If the reader must hold an undefined concept in working memory to understand the current paragraph, reorder.

Example: if "operation stack" depends on "operation" and "intent recognition", then §Operations must precede §Operation Stacks, and both must precede any section that combines them.

F9: Evaluation methodology clarity

Every RQ/experiment must answer four questions before presenting results. If any is missing, the reader sees numbers without understanding what they mean.

1. What claim is being tested? ("We test whether semantic labels separate system-effect weight that flat views mix.")
2. What is the setup? (Data, baselines, configuration — in concrete terms the reader can picture.)
3. What is the procedure? (What did you do, step by step, in 2-3 sentences? "We hide ground-truth labels, run the profiler, rank the resulting groups, and check whether top groups contain hidden positives.")
4. What metric answers the question? (Define every metric before using it. "Mixed-weight percentage: the fraction of system-effect weight in buckets containing observations from multiple semantic regions.")

Common failures:

• RQ jumps from setup directly to results, skipping the procedure
• Metric abbreviations appear in tables (AP, R@5, WTFP) without definition in prose
• Baselines are named but not described ("fixed-session:query-aware" — what does this do?)
• Configuration names in tables don't match prose descriptions ("op-stack" vs "operation-stack")
• Numbers are presented without stating what they mean: "AP = 0.312" without saying whether that's good or bad, and compared to what

Test for each RQ: after reading the RQ section, could a reviewer reproduce the experiment from the description alone (minus implementation details)? If not, the methodology is unclear.

---

X: Cross-Section Coherence

X1: Redundancy detection (Should fix)

Check whether any paragraph repeats content from a different section nearly verbatim. Common offenders:

• Design section repeating Background definitions
• Evaluation section re-explaining the design
• Related work re-stating the problem from the intro

Grep method:

# Find sentences that share long n-grams across sections
grep -n 'distinctive phrase from section A' file.tex

If a section needs to reference content from another section, use a forward/backward reference (as described in §X) rather than repeating.

X2: Claim-evidence alignment

For each claim in the introduction/abstract, verify:

1. The claim has corresponding evidence in the evaluation
2. The evidence section references the correct claim
3. Numbers in abstract/intro match numbers in evaluation tables

X3: Term stability across sections

Check that key terms defined in one section are used identically (same spelling, same hyphenation, same capitalization) in all other sections.

# Check a key term across the paper
grep -n 'operation stack\|operation-stack\|Operation Stack\|OperationStack' file.tex

X4: Declare system status upfront

Do not bury "this is a prototype" or "this is future work" at the end. State explicitly whether the system is fully implemented, a prototype, or hypothetical, so reviewers know what they are evaluating. (Levin & Redell)

X5: Cite by author

Use "Smith et al.~[5] show..." rather than "[5] shows..." for readability and proper credit. Place the citation near the author name.

Bad: [5] shows that flame graphs reduce debugging time. Good: Gregg~[5] shows that flame graphs reduce debugging time.

X6: Numbers are claims

Every number in the paper needs a source (measurement, citation, or derivation). For experimental numbers, state repetitions, duration, object sizes, and hardware where applicable.

X7: Forward reference cost audit

Each forward reference ("§3 will describe...", "we detail this in §5") asks the reader to hold an IOU in working memory. Too many IOUs and the reader loses trust.

Check: count forward references. More than 3-4 in the intro or more than 2 per body section is a warning sign. For each one, ask: does the reader need this promise to follow the current paragraph? If not, delete the forward reference and let the reader discover the section naturally from the paper structure.

---

Output format

For paper-consistency scope, use the complete output contract in references/paper-consistency.md.

For terminology-infoflow or combined scope, use the format below; in combined scope, include factual consistency blockers before readability findings.

For each issue found:

L<line>: "<quoted text>"
  Category: J1/C2/F3/X1/etc.
  Problem: <what's wrong and why the reader is confused>
  Fix: "<suggested rewrite>"

Group by severity (Must fix → Should fix → Consider), then by category within each group.

End with:

• Summary table: issues by category and severity
• Top 3 most impactful changes (the ones that most improve readability)
• Any patterns observed (e.g., "project vocabulary leaks concentrated in §5")

After all fixes, recompile and verify page count unchanged.