ACE — Reverse Analyzer Flowchart (Current Engine / File-Aware)

• Handled in ace/tools/ace_reverse_assessor.php
• Input may come from GET, POST, test token arrays, or plain text with spaces
• Text normalization helpers split commas / spaces / newlines into token lists

• Lowercase transliteration
• Trim whitespace
• Preserve digraph units such as sh, kh, dh, gh, th
• Preserve long vowels and sequences such as aA, iy, uw, AA
• No POS assignment yet

• From ace/tools/bootstrap_rules.php
• Includes consonant/vowel primitives such as ACE_C
• Includes shared suffix catalogs such as: $PERF, $IMPF, $OBJ, $AMR, $NOMINAL

• ACE reads tokens in order, not only as isolated forms
• The previous token may govern the mood or strengthen one family of analysis

• Perfect-supporting particles such as qad
• Subjunctive governors such as lan, ean, kay, HattaA
• Jussive governors such as lam, lammaA, and command-related li
• Future or modal support such as sa, sawfa

A governing particle does not automatically erase all other analyses, but it can raise the score of a matching imperfect or perfect candidate.

• Done early in the main engine/helpers, before deeper morphology
• Typical proclitics include: wa, fa, la, bi, li
• Combined openings such as wal and fal must be supported when valid

• The stripped left piece is recorded as prefix
• The remainder is sent to exact lookup and morphological routers
• Prefix is not allowed to corrupt root extraction

• The raw token may be exact
• The stripped remainder may also be exact
• The stripped remainder may expose imperfect / imperative / nominal evidence

• Main helpers in tools_functions2.php consult local non-derived data
• Primary source: ace/data/include_particles.php
• Categories include particles, pronouns, prepositions, conjunctions, demonstratives, relatives, interrogatives, and other fixed entries

• Full surface token first
• Then post-prefix remainder where appropriate
• Then simple exact-plus-suffix variants where supported

If a token is a strong exact / non-derived match, ACE should preserve that instead of misclassifying it as a verb or noun merely because the letters resemble a pattern.

• Examples: hu, hum, humA, hunna, haA, ka, ki, kum, kumaA, naA, niy
• These are stored as removed tail or object suffix evidence

• Perfect endings are tested in perfect routing
• Imperfect endings are tested in imperfect routing
• Imperative endings are tested in imperative routing
• Nominal declension endings are tested in nominal routing

This is one of the biggest differences from the old flowchart. ACE no longer does one blind global strip pass and then guesses.

• Helpers such as suffix-variant builders in tools_functions2.php generate alternate stem states
• These alternates are passed into family-specific rule chains

• Exact / Non-Derived
• Perfect Verb
• Imperfect Verb
• Imperative Verb
• Nominal / Participle / Verbal Noun

• Each family may emit one or more candidates
• Each candidate keeps its own evidence trail
• Later ranking decides which candidate is best

• token
• prefix
• rest
• suffix
• removed tail
• stem used
• root
• form
• pattern
• tense / voice
• pronoun
• confidence

• Main rule file: ace/tools/rules/perfect_active.php
• Tests Form I patterns and higher forms II–X
• Includes strong, doubled, and derived patterns

• Main rule file: ace/tools/rules/perfect_passive.php
• Uses passive vocalization patterns for Forms I–X where valid

• Uses $PERF family endings from bootstrap support
• Examples include: tu, ta, ti, tum, tumaA, tunna, naA, na, at, aA, uw

If perfect morphology plus suffix evidence plus root support is strong, it should outrank a weak nominal guess.

• Main helpers detect prefixes such as: ya, yu, ta, tu, na, nu, ea, eu
• This logic is handled in helpers and imperfect routing code

• Rule files include: imperfect_active_strong.php, imperfect_active_assimilated.php, imperfect_active_hollow.php, imperfect_active_duplicated.php

• Rule files include passive counterparts such as: imperfect_passive_*.php
• Passive and active are evaluated separately

• Indicative
• Subjunctive
• Jussive
• Light emphatic
• Heavy emphatic

Candidate selection may be strengthened by particle context from the preceding token.

• Uses endings from $IMPF
• Examples: u, a, i, an, in, un, aA, iy, na, uw, aAni, iyna, uwna

• Main rule file: ace/tools/rules/imperative.php
• Imperative is not treated as a damaged imperfect
• Restricted to second-person logic

• Uses the $AMR suffix family
• Typical endings: Ø, iy, aA, uw, na

• ACE should recognize combinations such as imperative stem + ending + object tail
• Example logic: kaAtib + iy + naA

• Examples include: qi, qul, kun, sir, khaf
• Weak classes are not postponed to some final repair stage

• active_participles.php
• passive_participles.php
• verbal_nouns.php
• adjectives.php
• instruments.php
• colors_and_defects.php
• broken_plurals.php

A bare stem with no valid nominal evidence must not automatically be labeled as a noun.

• Prefer explicit declension support
• Prefer strong nominal pattern support
• Do not let weak noun guesses outrank strong verbal evidence

• Uses $NOMINAL support from bootstrap_rules.php
• Includes singular case endings, tanwīn, dual, sound plurals, etc.
• Examples: u, a, i, un, an, in, aAni, ayni, uwna, iyna

• Examples: mu, ma, mi, musta
• These must still be supported by pattern and suffix evidence

• Main helpers in tools_functions2.php extract consonantal frames
• Digraph consonants remain atomic
• Gemination / doubled radicals are allowed where required

• Form I: base classes and reduced variants
• Form II: geminated second radical
• Form III: aA after first radical
• Form IV: ea / eu openings in valid environments
• Form V: ta + Form II behavior
• Form VI: ta + aA
• Form VII: ein / in / ink patterns
• Form VIII: inserted t, including assimilation behavior
• Form IX: color/defect patterns
• Form X: sta / sti

• Strong
• Assimilated
• Hollow
• Defective
• Doubled / duplicated
• Hamzated
• Doubly weak

• Inserted t may assimilate in surface forms
• ACE should not require only textbook unassimilated shapes

• Translation support comes from: ace/tools/translation_functions.php
• Dictionary data comes from: ace/data/dictionary_loader.php
• Root-based lookup prefers a base/Form I semantic anchor

• Add English gloss
• Add Urdu gloss
• Add base English / base Urdu if available
• Adjust meanings according to detected form or noun type

A candidate with a valid supported root and usable gloss generally ranks above a structurally weak candidate with no lexical support.

• Exact match strength
• Family-specific suffix validity
• Pattern-form agreement
• Root plausibility
• Dictionary / translation support
• Particle-context agreement
• Penalty for over-stripping or implausible stems

• The top candidate becomes the main visible analysis
• Alternate matches may still be shown in the match bundle

• Token
• Prefix
• Rest
• POS
• Category
• English
• Urdu
• Tense / Voice
• Form
• Pattern
• Root
• Suffix
• Removed Tail
• Stem Used
• Pronoun
• Confidence
• Match Count

• Do not do one blind suffix strip and then guess
• Do not misread imperative as broken imperfect
• Do not allow exact particles/pronouns to be swallowed by morphology
• Do not label bare stems as nouns without real nominal evidence

• Protect exact/non-derived items early
• Peel proclitics early and record them separately
• Route into competing families
• Strip suffixes in family-aware ways
• Use particle context to break ties
• Use dictionary/root support to strengthen valid analyses

Current ACE model: normalize → preserve context → peel proclitics → protect exact matches → route by family → test suffix families carefully → enrich → rank → display