Invented-script name codec

An inscription can be consistent and still be misunderstood

You have drawn a sign for a station, a person or a house in an invented writing system. It looks right beside the other signs. You can explain every symbol. That does not yet establish what a reader following your own rules will recover from it. A long mapping can overlap two short mappings, and one symbol can have two permitted expansions. The inscription may carry a different name without any individual rule being broken.

This codec applies literal mappings you supply. It counts complete ways to segment the current input, shows a limited set of derivations and groups displayed derivations that produce the same output. For each displayed output, it then examines the complete inverse conversion and counts how many inverse derivations return the exact original input. If some lead elsewhere, it supplies an actual counterexample.

The task is designing an authored representation, not transliterating a real language. There is no inferred sound, cultural meaning, historical alphabet or authority behind the default symbols. If a story needs real orthographic conventions, research those separately. Here, the author is responsible for declaring the small writing system that the program can inspect precisely.

Original fictional scene: the station with two readings

The new miniature railway had two stops, Varen and Vali. Their names belonged to the maker’s fictional setting, and the sign painter was allowed to invent its symbols. In the painter’s worksheet, va became △, ren became □, and the whole name varen could also be written △□. A fourth rule gave li the same square used for ren.

At the opening, the first visitor read the two-symbol station sign as Vali. The painter pointed to the whole-name rule and said it was Varen. Neither had ignored the worksheet. The visitor had used va followed by li, while the painter had used varen as a single unit. The maker could not repair the disagreement merely by printing the sign more neatly.

There were two separate matters to decide. Varen could be encoded as one whole-name unit or as va followed by ren, with the same visible result. That redundancy did not change the name. The shared square, however, allowed an inverse result of vali. The painter had treated different segmentations and different readings as if they were the same kind of uncertainty.

For the working timetable, the maker changed li to ●. Vali now had a distinguishable sign. The two ways to derive Varen remained, because they both led back to the same exact plain text. Beside the display, the maker kept a small drafting sheet showing why the earlier sign had confused a visitor. The exhibition could explain a design choice without claiming that one person had failed to understand a uniquely readable instruction.

The railway, maker, painter, visitor and symbol rules are original fiction. They do not establish anything about an actual name called Varen or Vali. If the fourth mapping were retained deliberately, the ambiguous sign could instead become a clue: a character would need another piece of context to choose a reading. The tool can show the alternatives, but it cannot decide whether that uncertainty is fair in your scene.

Try the counterfactual in your own setting. Replace the square assigned to li with a distinct symbol, then examine the inverse count again. If you only rename the station in prose while leaving the encoded sign unchanged, the same collision may remain. A meaningful name revision includes the representation that other characters actually encounter.

Write a mapping contract before treating it as a language

Each rule has exactly id, plain and encoded. The ID is a stable ASCII-letter-led label of at most forty letters, digits, underscores or hyphens. Each mapping side contains one to eight Unicode code points, with at most sixteen UTF-16 units and no control characters. The worksheet accepts one to eighty rules. No rule can consume or produce an empty unit, which prevents an empty expansion from introducing unlimited derivations.

Identical mapping pairs are rejected even when their IDs differ. They would count duplicate records rather than different writing choices. Shared plain sides, shared encoded sides and overlapping prefixes are permitted, because those are precisely the situations worth inspecting. The shared-side table highlights literal repetitions; the complete segmentation calculation determines whether they matter for the current input.

The default four rules are va → △, ren → □, varen → △□ and li → □. These are authored units, not asserted syllables or translations. You may use other literal units, including kana or supplementary-plane symbols, but the software does not decide what those units sound like. A mapping from a written unit is a declared operation, not evidence of an etymology.

Comparison is exact. There is no Unicode normalization, case folding, punctuation removal or automatic handling of unknown text. A composed character and a visually similar decomposed sequence can behave differently. Preserve the input you intend to use in the actual artwork or game data, and make any normalization policy outside this model explicit before comparing results.

Follow the complete input, not just the longest-looking rule

The input may contain at most eighty code points and 160 UTF-16 units. Choose encode for plain units to symbols, or decode for symbols to plain units. The program considers all rules that match at an input position and follows only segmentations that reach the end. A locally plausible long match is not automatically the correct one.

For example, suppose the rules can consume abc, ab and cd, and the input is abcd. Taking abc first leaves an unmatched d. Taking ab and then cd can complete the input. A longest-match shortcut would miss that route. The workbench’s derivation trace instead shows the rule IDs and exact source spans that actually produce a complete conversion.

Spans are one-based and refer to code points, not bytes or the number of UTF-16 units. The source positions let you compare a derivation with the original text without mistaking one supplementary-plane symbol for two separate letters. They do not claim that the unit corresponds to a reader-perceived grapheme or an approved pronunciation segment.

If there is no complete parse, the result is empty. The report shows the furthest reachable input prefix and the remaining text after it. That is a diagnostic for one furthest point, not a claim that every earlier segmentation was valid or that the remaining character is the only thing to fix. Unknown material is never dropped to create an attractive-looking inscription.

Count derivations and readings separately

Encoding varen with the default rules has two derivations. One uses the whole-name rule; the other uses va and ren. Both produce △□. The interface groups those displayed derivations into one output card, retaining their separate source traces. Calling that card “two different names” would be wrong.

Decoding △□ gives three derivations. The whole-name rule returns varen; va plus ren also returns varen; va plus li returns vali. There are three derivations and two distinct decoded names in this fully displayed example. A shared mapping side is not the whole explanation: variable-length segmentation also determines which combinations can complete the inscription.

The sample limit, from one to twelve, controls how many forward derivations are shown. The total derivation count remains exact and is represented as a decimal string. If you display only one of the three derivations, the report cannot claim to have enumerated all distinct outputs. It labels the remaining scope as uninspected rather than turning one visible card into a uniqueness certificate.

This distinction matters when your rules are intentionally redundant. Several spellings might encode one chosen name, or several unit boundaries might explain one spelling. You can retain those design choices while investigating the genuinely different decoded strings. Do not remove useful redundancy merely because the derivation count is greater than one.

Ask the inverse a precise question

For each displayed output, the inverse check asks: how many complete inverse derivations exist, and how many return this exact original input? It uses the complete inverse graph, independently of the forward display limit. It does not sample a few return paths and assume that the others agree.

With the default input varen, the output △□ has three inverse derivations, of which two return varen. The other returns vali, and its rule sequence is available as a concrete counterexample. Changing li to ● leaves two inverse derivations of △□, both returning varen. The segmentation remains nonunique while the inverse result for this particular input is now consistent.

The proof is scoped to one displayed output and the current original input. It does not establish that the entire invented writing system is reversible for every possible name. In decode mode, both varen and vali can encode back to the same original inscription; that fact does not make the forward decoding unique. Multiple displayed forward outputs remain an unresolved choice even when each one returns correctly in the opposite direction.

The workbench can count very large derivation sets without converting the count into an imprecise numeric score. That is a property of the finite calculation, not a measure of how confusing a sign will feel to readers. Actual recognition, context and typography can add questions that this literal mapping model does not answer.

Inspect an alternative before changing the source

Use the opposite-direction control to put a displayed output into the input field and switch the conversion direction. The button checks the current rules, source text, direction, sample limit and private context before replacing anything. If those changed since the output was displayed, recompute first. An old inscription is not automatically valid evidence for the new worksheet.

Some extreme generated outputs can exceed the editable eighty-code-point input limit. Their inverse proof is still calculated, but the interface does not offer a button that would insert an invalid editable input. This is a stated worksheet boundary, not silent truncation. Shorten or separately scope that authored representation if you need to edit it as a fresh source.

Keep the private story context useful. Write whether the inscription is meant for a timetable, a personal seal, an unreliable quotation or a puzzle’s deliberate ambiguity. These notes do not alter the parser or become invented cultural facts. They help explain why you retained or repaired a particular mapping when returning to the design later.

Copying, favorites, comparison and the audit export contain exact rules, source text, derivation traces, inverse results and private story notes. A saved project restores an editable worksheet, not a spoiler-safe artifact for players. Review the intended audience before sharing it. Use the physical lettering or ruby tools separately when the next question is whether the chosen representation fits an actual production frame.

Does this transliterate a real language?

No. You supply an invented correspondence. Exact matching establishes behavior within those rules, not an authentic reading, cultural meaning or attested script.

Do two derivations always mean two names?

No. Two rule sequences may produce the same inscription and both inverse paths may return the same original name. The tables separate derivation counts from distinct displayed outputs.

Does a sample cap limit the inverse proof?

No. The forward cap limits displayed derivations. Every displayed output receives a complete inverse count and a complete count of returns to the original input. Undisplayed forward outputs have not been individually audited.

Does successful return prove my entire alphabet is reversible?

No. It concerns the displayed output for this exact input and rule set. Test other names and boundaries separately; shared-unit flags alone neither prove nor disprove every possible use.