Abstract Logic Writer

Overview

Use symbolic discourse constraints and a lightweight ontology to draft or critique English academic abstracts. Treat abstract writing as a constrained mapping from propositions to an ordered sentence sequence, not as free-form style imitation.

Core workflow

1. 1. Build a proposition set P = {background, status, motivation, challenge, idea, technique, evidence} from the user's notes.
2. Choose the shortest valid role chain whose image still contains motivation, challenge, and idea. The default 4-5 sentence chain is M -> C -> I -> T -> E, with optional background or status prepended.
3. For each sentence, write a micro-structure general -> specification -> consequence/purpose. Do not place a narrow detail before its governing concept.
4. Load references/computable-rules.md as the primary specification. Load references/lexeme-typing.md and assets/lexeme_types.json when verb-noun fit is uncertain.
5. If the domain terminology is sparse or unstable, load references/ontology-bootstrap.md and optionally run:

1. 6. Before finalizing, run:

Drafting discipline

• - Assign each sentence exactly one primary discourse role.
• Never output a sentence that only labels a condition without causal or purposive load. Reject patterns like X is a challenge. unless the sentence continues with cause, consequence, or operational relevance.
• When introducing a new concept x, attach motivation, purpose, or consequence within the same sentence or an adjacent sentence.
• When explaining a mechanism, state what it enables, stabilizes, reduces, or preserves.
• Prefer typed predicate selection over idiomatic guesswork. Example: traffic grows, demand increases, applications develop, systems evolve, accuracy improves, continuity is maintained.
• Avoid common AI-sounding markers. Do not use the em dash or Unlike unless the user explicitly asks to preserve source wording.
• Do not end with a generic recap sentence. The last sentence must carry evidence, operational implication, or measured outcome.

Output modes

1. Draft from notes

Return:

1. 1. an optional symbolic plan when the source notes are underspecified,
2. the final abstract,
3. concise lint notes only when there are nontrivial tradeoffs.

2. Critique or rewrite an existing abstract

Return:

1. 1. a violation list keyed to the symbolic predicates in references/computable-rules.md,
2. a repaired abstract,
3. the smallest possible set of lexical substitutions when the main issue is verb-noun mismatch.

3. Produce negative examples

Use references/negative-examples.md.
Generate intentionally flawed rewrites that violate one or more named predicates such as summary_only, selection_mismatch, scope_inversion, or forbidden_marker.
Label each negative example with the violated rules. Do not present it as recommended style.

Resource map

• - README.md: GitHub-facing quick start and repository guide.
• INLINECODE32: formal sentence and discourse constraints.
• INLINECODE33: upper ontology for noun classes and verb selection.
• INLINECODE34: domain ontology construction and download workflow.
• INLINECODE35: contrastive negative examples and rule tags.
• INLINECODE36: raw domain corpus supplied by the user.
• INLINECODE37: heuristic checker for role order, banned markers, and selection mismatches.
• INLINECODE38: formulaic scorer and comparator for one or two abstract fragments.
• INLINECODE39: generate a seed ontology or download a public ontology file.
• INLINECODE40: machine-readable role order, forbidden patterns, and score weights.
• INLINECODE41: machine-readable lexeme typing rules.
• INLINECODE42: before-and-after fragments for quick scoring demos.
• INLINECODE43: sample scoring outputs for repository documentation.

Working defaults

When the user does not provide all paper details, infer the missing low-risk connective tissue from the available propositions and state the assumptions briefly. Keep the prose compact, domain-accurate, and hierarchy-aware. Prioritize logical fit over rhetorical flourish.