ABCDE 1.0 design pass: formalize the language before translator / tiny-native-agent experiments

[yo4e]

Status

Design / research issue. Not an implementation commitment and not urgent.

This issue is the umbrella for a deliberate consistency and design pass over ABCDE Language before building software or learning systems around it.

The intended long-term sequence is:

1. Stabilize ABCDE itself
2. Build a translator / interpreter / reference implementation
3. Much later, experiment with an extremely small ABCDE-native agent / model / artificial-life-like organism

The language should be coherent enough that later odd behavior can be attributed to the translator, learner, architecture, environment, or emergent convention — rather than to contradictions in the language definition itself.

Related: #2 collects several concrete documentation/spec inconsistencies. This issue is broader: it should decide the underlying design before those inconsistencies are patched one by one.

---

Long-term design goal

A useful target is:

ABCDE should be a language that is small enough for a human to learn quickly, formal enough for a machine to interpret without hidden human common sense, and simple enough that a very small learner could potentially acquire grounded meanings through interaction.

This is stronger than merely making the README internally consistent.

If successful, ABCDE could serve simultaneously as:

• a tiny human communication system;
• a formally specified constructed language;
• a reference language for parser / translator experiments;
• a minimal semantic interface for simulated environments;
• a possible native language for very small artificial agents;
• a testbed for studying grounding, convention formation, ambiguity, compositionality, and language emergence.

The goal is not to make ABCDE more elaborate. The goal is to make its smallness precise.

---

1. First design question: what kind of language is ABCDE?

The current documents mix two possible models.

Model A — compositional semantic system

The 8 atoms are semantic primitives. Compounds are interpreted productively from those primitives.

Example:

• CE = positive / desirable
• CA = matter / thing / fact
• CECA = composition of CE + CA, approximately “positive/desirable thing”

Under this model, “food” may be a common contextual interpretation of CECA, but does not need to be an arbitrary lexical fact that every learner memorizes.

Model B — tiny-root lexical language

The 8 atoms are roots from which many conventional words are formed.

Under this model:

• CECA = food
• DACA = tool
• BACA = person
• BADACA = plant
• etc.

are ordinary lexical conventions that must be learned.

Both models are possible, but they lead to very different languages.

Recommendation

Strongly investigate Model A, or a hybrid with a strict separation between compositional meaning and conventional lexical readings.

Reason: this preserves the claim that ABCDE is fundamentally tiny, makes independent interpretation more tractable, and creates a much cleaner foundation for translator and learning experiments.

If every compound eventually becomes a memorized word, ABCDE risks becoming an ordinary constructed language with only a small root inventory.

---

2. Proposed three-layer model

A useful architecture may be to explicitly separate:

Core

The normative, minimal language mechanism:

• the 8 atoms;
• their core semantic contribution;
• composition rules;
• grammatical markers;
• scope;
• word order / role assignment;
• omission rules;
• sentence boundaries;
• validity rules.

The Core should be small, explicit, and stable.

Conventions

Shared human interpretations / lexicalizations that are useful but not fundamental truths of the grammar.

Examples might include:

• CECA commonly interpreted as food;
• BABE commonly interpreted as friend;
• culturally shared readings of colors, greetings, natural units, etc.

A convention may be conventional without becoming a new primitive.

Grounding

Mappings between ABCDE expressions and things, states, actions, perceptions, or rewards in a real or simulated world.

Examples:

• which observed objects are treated as CECA;
• which direction/action becomes associated with a motion expression;
• whether a learner independently associates a recurring visual property with a conventional color reading.

This distinction matters enormously for later artificial-life / tiny-agent experiments. A learner should not be credited with acquiring a concept that was secretly hard-coded into a dictionary or environment adapter.

---

3. Define the semantics of the 8 atoms more rigorously

The current atoms are evocative, but several cover multiple conceptual roles:

• A: Motion / Future
• E: Relation / Past
• BA: Self / Origin
• BE: Other / Target
• CA: Matter / Fact
• CE: Positive / Order / Good
• DA: Action / Power
• DE: Negative / Chaos / Bad

Questions to resolve:

• Is each atom a semantic type, a semantic feature, a relation, an operator, or a broad conceptual field?
• Are the English glosses normative meanings or only teaching hints?
• Why does “motion” license future tense?
• Why does “relation” license past tense?
• Does BA always encode speaker/self, or more abstract origin/source?
• Does BE encode addressee, otherness, destination, or target?
• Does CA distinguish object, substance, proposition/fact, and entity?
• Are CE / DE valence judgments, truth values, preference, order/chaos, or all by context?
• Is DA an action predicate, force, causation, change, or eventhood?

A good outcome would not necessarily assign one narrow English word to each atom. It may instead define a small semantic invariant plus explicitly permitted contextual extensions.

---

4. Make composition actually formal

The current rule says Modifier + Head, with the final atom determining the kind/category of the compound.

That rule is potentially very powerful, but “kind/category” is not yet formally defined.

Questions:

• What categories can atoms head?
• If the last atom is CA, must the result be entity/fact-like?
• If the last atom is DA, must the result be action/event-like?
• What does a compound ending in CE, DE, A, E, BA, or BE denote?
• Is composition binary and recursive?
• Are compounds always parsed from left to right, right to left, or by a fixed tree rule?
• Is BADACA necessarily BA + DA + CA, (BA + DA) + CA, or BA + (DA + CA)?
• Can the same surface string have multiple compositional parses?
• At what point does a conventional lexical reading override or specialize the compositional reading?

This matters because some current dictionary entries do not obviously obey the stated head rule. For example, place-like meanings such as ACE / ADE require a clearer account of why a compound ending in CE / DE denotes a place.

Desired property

Given an unfamiliar well-formed compound, an independent implementation should be able to produce at least a coarse structural interpretation from the Core alone.

---

5. Treat polysemy deliberately, not automatically as a bug

Issue #2 identifies several collisions such as:

• A: future/motion vs white/light;
• ACA: here vs day vs red;
• ADA: go/walk vs water/drink/blue.

These may be genuine contradictions — but they may also be evidence that ABCDE is trying to represent semantic fields rather than dictionary words.

Before renaming or splitting them, decide:

• Is the polysemy intentional?
• Can all contextual readings be derived from a stable core meaning?
• Which readings are Core and which are Conventions?
• Is ambiguity acceptable here?
• What evidence/context disambiguates the reading?

Example design direction:

Instead of documenting:

ADA = go / water / blue

possibly document something closer to:

ADA: core compositional structure X; common contextual readings include movement/flow, and by convention water/drink/blue in relevant contexts.

This is only a design direction, not a proposed final definition.

---

6. Word order and semantic roles need a stronger decision

The current specification recommends roughly:

(sentence markers) -> subject/topic -> predicate -> object -> place -> time

but says word order is basically flexible and also permits broad contextual omission.

This creates a serious information problem in a language with an intentionally tiny vocabulary.

For example:

• BA CE BE
• BE CE BA

If word order is truly free, role assignment becomes unclear unless another mechanism exists.

Questions:

• Is the default word order merely recommended, or is it semantically significant?
• Which permutations preserve meaning?
• Is fronting allowed only for explicitly defined topicalization/emphasis?
• Are subject/object roles determined by position?
• Can semantic roles be inferred from atom type?
• How much ambiguity is acceptable?

Recommendation

Prefer a small but reliable canonical syntax over maximal free word order unless freedom can be formally interpreted.

The language can still allow conversational ellipsis and marked alternatives, but the canonical form should be recoverable and testable.

---

7. Omission / ellipsis needs an explicit ambiguity policy

Current ABCDE allows omission of subject, object, place, time, and other contextually recoverable information.

That is useful for human conversation, but software and learning experiments need rules for what an omitted expression means structurally.

Define at least:

• which roles may be omitted;
• whether omission creates an implicit variable / unknown role;
• whether omitted BA should ever be assumed automatically;
• whether conversational conventions may fill missing roles;
• when a sentence is valid-but-underspecified versus malformed;
• when a translator must return multiple readings rather than choose one.

A translator should not silently inject human common sense that the ABCDE sentence did not encode.

---

8. Distinguish lexical atoms from grammatical operators cleanly

The current language reuses atom forms as grammatical markers:

• A vs A- future
• E vs E- past
• DE vs DE- grammatical negation
• A! emphasis/exclamation
• E? question

This reuse is elegant, but scope and interpretation must be unambiguous.

Questions:

• Are the marked forms separate grammatical operators derived from the atoms, or contextual uses of the same atoms?
• Are their semantics compositionally related to the unmarked atoms?
• Can markers nest?
• Can multiple tense/mood markers coexist?
• What sequences are invalid?
• Does negation apply only to one word or can clauses/statements be negated?
• How is DE- distinguished robustly in speech?
• Are long-vowel marker pronunciations mandatory or recommended?

The current distinction between sentence-level A- / E- and word-level DE- is useful and should be made testable.

---

9. Clarify ordinary E as a relation operator

A current example is:

A- BA ADA ACA E 3ACA

intended roughly as “I will come here after 3 days.”

The problem is not necessarily misplaced past tense. E here appears to be the ordinary relation atom, not E-.

The real issue is that the grammar does not yet define how bare E links temporal expressions or other phrases.

Need to decide:

• Can bare E function as a general relation/link operator?
• What is its argument structure?
• Does X E Y mean relation-between(X,Y), after, from, with, and/or depending on context?
• How are temporal relations such as before/after distinguished if necessary?

This should replace the narrower diagnosis in #2 if the relation analysis is correct.

---

10. Sentence boundaries need a normative rule

Standard ABCDE does not use commas or periods.

Questions:

• How are multiple declarative sentences separated in writing?
• Is newline normative?
• Is a double space allowed/meaningful?
• Is there an end-of-sentence marker missing from the character set?
• In speech, is prosodic pause enough?

A parser needs a deterministic answer, even if human conversation allows looser realization.

---

11. Revisit numbers and the “8 sounds” claim

ABCDE has 8 semantic atoms, but spoken numerals currently introduce ten additional numeral pronunciations.

That is not necessarily a problem, but the claim should be precise:

• 8 semantic atoms, not literally 8 total spoken forms.

Also review whether the proposed numeral pronunciations satisfy the global-pronounceability goal. Some currently use language-specific phonetic material that may be harder than the core atoms.

Possible directions to compare:

• retain Arabic digits but leave pronunciation locale-dependent;
• define a simpler universal digit inventory;
• derive numbers compositionally from the 8 atoms;
• explicitly accept numerals as an external auxiliary subsystem.

Do not change this casually; test learnability, distinctness, speech recognition, and simplicity tradeoffs first.

---

12. Revisit “natural units” as Core vs Convention

Current examples use:

• ACA = day;
• BADA = step;
• DEDECECA = egg / egg-size.

These are attractive for a survival language, but they may be culturally/environmentally grounded conventions rather than universal Core semantics.

Questions:

• Is “day” a universal enough physical cycle to be Core?
• Is “step” observer-dependent but useful?
• Is “egg” too culturally/biologically specific to serve as a basic measurement reference?
• Should units live in a survival convention profile rather than the language Core?

---

13. External concept rule needs a formal boundary

Square brackets permit external words/proper nouns.

This is practical, but it can become an escape hatch that hides gaps in ABCDE.

Need to define:

• whether brackets are part of Core or an interoperability extension;
• whether arbitrary concepts or only proper nouns may be bracketed;
• whether bracket contents are semantically opaque;
• whether [X] is always treated as CA, person-like BACA, or typed by context;
• whether grammatical operations can modify bracketed expressions;
• how an ABCDE-only learner should handle bracketed forms.

For tiny-native-agent experiments, it may be useful to define a strict ABCDE mode with no external words.

---

14. Define normative vs illustrative documentation

Current README, specification, dictionary, and examples sometimes disagree or assign different levels of specificity.

A future implementation needs a clear authority hierarchy.

Suggested structure:

1. specification.md — normative Core
2. conventions.md or clearly marked dictionary sections — conventional meanings
3. examples.md — examples that must conform to the spec
4. README — teaching/overview only, never the sole source of a rule
5. adaptations.md — explicitly non-normative derivatives / orthographies

If dictionary.md remains, every entry should indicate whether it is:

• compositional gloss;
• conventional lexicalization;
• contextual reading;
• survival-profile term;
• external/derived extension.

---

15. Build a conformance corpus before the translator

Before implementing translation, create a small executable-or-machine-readable corpus containing at least:

Valid and unambiguous

Expressions for which the Core should yield one structural interpretation.

Valid but intentionally ambiguous

Expressions where the correct result is a set/range of readings, not a fabricated single answer.

Context-dependent

Expressions that become interpretable only with supplied context.

Invalid / malformed

Examples violating marker order, character set, compound grammar, sentence structure, etc.

Convention-dependent

Expressions whose specific human gloss depends on a shared lexical convention.

This corpus should become the first test suite for any parser, translator, or learner-facing environment.

---

16. Add a survival communication corpus

Because ABCDE explicitly prioritizes basic human connection and survival, design should be tested against actual communicative tasks rather than only cute dictionary examples.

Create roughly 50–100 scenario sentences / intentions such as:

• I need water.
• Do not eat that.
• This place is dangerous.
• Help me.
• Help that person, not me.
• I cannot walk.
• Are you hurt?
• There are three people.
• Food is over there.
• I will return in two days.
• Where are you going?
• Stay here.
• Fire is nearby.
• I do not understand.
• Yes / no / maybe / unknown, if those distinctions are required.

For each, record:

• intended semantic content;
• canonical ABCDE form;
• allowed shortened forms;
• ambiguity introduced by shortening;
• whether the expression relies on Convention or Core only.

This will expose missing distinctions much faster than editing the dictionary in isolation.

---

17. Translator should begin as a reference interpreter, not “Google Translate for ABCDE”

After ABCDE 1.0 is coherent enough, build a separate repository for a reference implementation.

Recommended architecture:

ABCDE surface text -> parse -> explicit intermediate semantic representation -> gloss / translations

Do not start with direct string-to-English/Japanese substitution.

The intermediate representation should preserve:

• atom structure;
• compound tree;
• grammatical markers and scope;
• semantic roles;
• omitted/unknown arguments;
• ambiguity;
• convention-dependent readings;
• contextual assumptions.

Possible outputs:

• structural gloss;
• Japanese candidate translations;
• English candidate translations;
• validation errors;
• ambiguity reports;
• confidence or required-context notes.

Important rule:

When ABCDE underspecifies something, the interpreter should report underspecification rather than silently inventing information.

This implementation then becomes an executable specification test for the language itself.

---

18. The translator can later become a teacher / instrumentation layer

A reference interpreter can also support later learning experiments by providing:

• canonical parses;
• controlled training pairs;
• environment annotations;
• semantic reward/debug signals;
• detection of malformed outputs;
• measurement of whether an agent uses syntax productively rather than memorizing strings.

But it should not be treated as proof that an agent understands ABCDE. A learner that imitates translator output may merely reproduce mappings.

---

19. Do not commit yet to Transformer as the tiny-native architecture

The future ABCDE-native “brain” should remain architecture-neutral at first.

Candidates may include:

• tiny Transformer;
• RNN / GRU;
• small recurrent state machine with learning;
• reinforcement-learning agent;
• predictive world model;
• neural cellular / artificial-life-like system;
• symbolic-neural hybrid;
• other deliberately tiny cognitive architectures.

The research question is more interesting than the model family:

What is the smallest system that can ground and productively use the ABCDE Core?

Avoid importing a huge pretrained model if the goal is to study genuine acquisition inside the ABCDE world. A large pretrained model already contains vast human language/world priors and would make “learning ABCDE” hard to interpret experimentally.

---

20. Possible minimal-world experiment

A later experiment could use an extremely small simulated environment containing only a few grounded distinctions, for example:

• self / other agents;
• food / harmful object;
• water or another resource;
• safe / unsafe location;
• motion/actions;
• simple time progression;
• positive/negative outcomes;
• communication signals composed only from ABCDE.

Questions the experiment could test:

• Can an agent associate expressions with grounded states/actions?
• Can it compose unseen combinations productively?
• Can it understand another agent’s novel compound?
• Can conventions emerge that were not preloaded?
• Can two agents develop stable local dialects?
• Can conventions drift while the Core remains stable?
• What minimum memory/model capacity is required?
• What failures come from cognition versus language ambiguity?

A later extension could potentially place such agents into another artificial-society experiment, but that should remain downstream of a stable ABCDE specification.

---

21. Preserve ambiguity when it is meaningful

The design goal should not be “eliminate every ambiguity.”

Natural interaction benefits from contextual compression. A tiny language may deliberately leave distinctions underspecified.

Instead classify ambiguity:

• structural ambiguity — multiple parses;
• lexical/conventional ambiguity — one structure, multiple shared readings;
• referential ambiguity — unclear object/person;
• contextual ellipsis — missing recoverable roles;
• intentional semantic breadth — an atom represents a broad field;
• specification bug — interpretations conflict because the rules are inconsistent.

Only the last category necessarily needs to be removed.

For every tolerated ambiguity, document what kind it is and what context can resolve it.

---

22. Consider explicit “strict” and “conversational” modes

One possible way to preserve human usability while supporting machines:

Strict / canonical ABCDE

• fixed canonical order;
• explicit arguments where needed;
• deterministic sentence boundary;
• no unexplained external words;
• formal marker order;
• intended for specifications, teaching, tests, parsers, and machine communication.

Conversational ABCDE

• context-driven omission;
• fronting/emphasis;
• conventional phrases;
• shorthand greetings;
• tolerated ambiguity.

This would let the language stay pleasant/minimal for humans without forcing parsers to treat every pragmatic shortcut as Core grammar.

This is only a proposal to evaluate; avoid adding modes if one clean grammar can handle both.

---

23. Add machine-readable specification data eventually

After semantic decisions are stable, consider adding a tiny machine-readable representation (JSON/YAML/etc.) for:

• atom inventory;
• markers;
• valid character set;
• canonical grammar;
• conventional lexicalizations;
• conformance examples.

This should be generated from or checked against the normative human-readable spec, not become an uncontrolled second specification.

Benefits:

• translator tests;
• linting docs/examples;
• environment generation;
• tiny-agent experiments;
• automatic consistency checks.

---

24. Version the language once the Core starts stabilizing

Before external implementations depend on ABCDE, define a lightweight versioning policy.

Example:

• 0.x — experimental, breaking semantic changes allowed;
• 1.0 — Core grammar/semantics considered stable enough for independent implementations;
• later minor versions — additive conventions/examples;
• breaking Core changes — explicit major revision.

A language version should identify the specification, not the translator implementation.

---

25. Possible design principles for ABCDE 1.0

These are proposed principles to evaluate and refine:

1. Eight semantic atoms remain the conceptual foundation.
2. Every Core rule must earn its complexity.
3. Unknown compounds should remain partly interpretable.
4. Conventions must not masquerade as primitive semantics.
5. A machine should be able to preserve ambiguity explicitly.
6. Human common sense must not be silently required for normative parsing.
7. Canonical expressions should be mechanically testable.
8. Conversational compression is allowed only when its information loss is understood.
9. External vocabulary is interoperability, not a substitute for Core design.
10. The survival-first purpose should be tested with scenarios, not asserted only in prose.
11. The language should remain learnable without requiring a large hidden dictionary.
12. Future learning experiments should distinguish built-in semantics from acquired grounding and social convention.
13. Do not optimize the language specifically for one model architecture.
14. Prefer explicit uncertainty over fake precision.
15. Smallness means low conceptual machinery, not merely short documentation.

---

26. Proposed work sequence

No need to rush this. A careful sequence could be:

Phase A — semantic audit

• inventory every current atom use;
• inventory every compound in README/spec/dictionary/examples;
• identify which readings are compositional, conventional, contextual, or contradictory;
• resolve the Core-vs-lexicon question.

Phase B — grammar audit

• canonical order;
• role assignment;
• marker scope/order;
• negation;
• question/emphasis;
• tense/time relations;
• omission;
• sentence boundaries;
• external concepts.

Phase C — rewrite the normative spec

• define Core first;
• move conventions out of normative semantics where appropriate;
• make README and examples derive from the spec rather than introduce new rules.

Phase D — conformance + survival corpus

• valid / invalid / ambiguous examples;
• 50–100 survival intentions;
• machine-readable fixtures if useful.

Phase E — ABCDE 1.0 review

Ask whether two independent implementers could reasonably agree on:

• whether an expression is valid;
• how it parses;
• what semantic structure it conveys;
• what remains ambiguous;
• which reading depends on convention/context.

Phase F — separate translator/reference-interpreter project

Only after the language passes the above review.

Phase G — tiny-native-agent experiment

Only after the reference interpreter and grounding boundaries are clear enough to make experiments scientifically interpretable.

---

27. Suggested exit criteria for “ABCDE 1.0 ready enough”

Not perfection. Something like:

• Every one of the 8 atoms has a documented semantic invariant.
• Compound parsing/composition is formally described.
• Canonical sentence structure and semantic roles are defined.
• Marker scope/order is deterministic.
• Sentence boundaries are defined.
• Ellipsis behavior is classified.
• Core vs Convention vs Grounding is documented (or an alternative model is deliberately chosen).
• Current known collisions from [spec/docs] 仕様と例文・辞書の間にある意味の重複・矛盾の報告 #2 are resolved or explicitly accepted as designed polysemy.
• README/spec/dictionary/examples no longer contradict each other.
• Normative vs illustrative documents are clearly identified.
• A conformance corpus exists.
• A survival communication corpus exists.
• Ambiguity has an explicit representation/policy.
• External-word behavior is specified.
• Numerals and pronunciation claims are internally consistent.
• Two independent parsers could be implemented without inventing major missing grammar.

At that point, a translator/reference implementation becomes useful as validation rather than as a patch over underspecified language rules.

---

Non-goals for this issue

• Do not immediately build the translator.
• Do not immediately build a Transformer/LLM.
• Do not maximize vocabulary coverage.
• Do not remove every ambiguity merely because it exists.
• Do not make ABCDE “more natural-language-like” by default.
• Do not optimize for commerce or general bureaucratic precision if that conflicts with the survival/minimalism concept.
• Do not preserve existing examples at the cost of a cleaner Core; this repository is still early enough to revise them deliberately.

---

Why this matters for the future tiny-native system

The later experiment becomes much more interesting if an ABCDE-speaking organism does not begin with a hidden English/Japanese dictionary in its head.

Ideally, some distinctions are built into the Core, while grounded meanings and social conventions are learned through experience.

Then we can ask meaningful questions such as:

• Did the agent learn that a certain environment object is CECA, or was that mapping preloaded?
• Did two agents invent a stable new convention?
• Did an apparently strange utterance arise from an ambiguous spec or from a learned dialect?
• Can the agent generalize a compound it has never seen before?
• How much cognitive machinery is needed before compositional ABCDE becomes useful?

That is the reason to do the language-design work first.

The aim is not simply to produce a prettier conlang specification. It is to make ABCDE a small, inspectable linguistic substrate on which later translation, grounding, learning, and artificial-life experiments can be trusted.

[yo4e]

Addendum: preserve the current language as ABCDE v0 before the 1.0 redesign

Before making breaking design changes for ABCDE 1.0, preserve the current specification as a reproducible ABCDE v0 baseline.

Proposed policy

• Treat the current pre-formalization language as ABCDE v0, the original experimental design.
• Before redesign work begins, create an immutable Git tag at the current baseline commit (for example v0.1.0; choose the exact version when doing the preservation work).
• Prefer also creating a GitHub Release such as “ABCDE v0 — original / pre-formalization design” with a short explanatory note.
• Optionally create a human-browsable legacy/v0 branch if useful, but the Git tag should be the canonical immutable preservation point.
• Keep main as the current canonical specification and let it evolve toward ABCDE 1.0.
• Once the redesigned Core is stable enough, tag/release it as v1.0.0.

Do not duplicate the old specification inside main

Avoid keeping old/, v0/, or similar duplicate README/specification/dictionary trees on the current branch unless a later concrete need justifies it. Duplicate normative-looking files would make humans and tools uncertain about which version is authoritative and could cause automated agents to edit or reason from obsolete material.

History lives in Git tags/releases; the current language lives on main.

Naming and continuity

Call the preserved original ABCDE v0, not a failed/discarded language. It is the prototype / pre-formalization form of the same project. The redesigned language should remain ABCDE v1, unless the redesign eventually becomes so radical that semantic continuity is genuinely lost.

Why preserve v0

The v0 snapshot can later serve as an experimental baseline for comparisons such as:

• parser ambiguity in v0 vs v1;
• survival-corpus expressibility;
• amount of convention/lexical memorization required;
• translation determinism;
• learnability by tiny ABCDE-native agents;
• emergence of conventions under different Core designs;
• possible transfer between v0 and v1 learners.

This archival step should happen before the first breaking ABCDE 1.0 design change is merged.