PROGRAM_CHARTER.md

Seven-Model and Genesis Program Charter

Charter version: 1.0

Effective date: 2026-08-08

Status: authoritative cross-repository direction

Canonical copy: https://github.com/dakuwonmoody-lab/EsoM/blob/main/PROGRAM_CHARTER.md

Read this first

This charter exists so work in one repository does not lose the direction of the whole program.

The program is building one AI business with seven selectable model families: BulmaX, Beerus, NYS, AXIOM, Mech, EsoM, and WHIS. They are not seven personas on one hidden model. Each is a distinct attempt to build useful intelligence from a different computational substrate.

Genesis is not an eighth model. Genesis is the long-term hardware compute- substrate program intended to discover, falsify, and eventually embody new computational principles in non-CUDA physical hardware.

Anyone—human or agent—working in any participating repository must preserve these identities and boundaries unless an explicit cross-program decision changes this charter.

Mission

Within one outside-user-oriented product, a user should be able to select any of the seven models and interact with that model's real native computation. The models may have very different maturity, fluency, latency, memory, and availability. Those differences must be visible rather than hidden.

The long-term ambition is not a conventional weak-to-strong size ladder. It is a catalog of genuinely different kinds of machine intelligence sharing one product surface, account system, safety boundary, and business identity.

The seven model theses

Model	Durable architectural thesis	Intended character when mature
BulmaX	Adaptive multimodal autoregressive neural generation	Broad, fluent generalist
Beerus	Recurrent byte processing coupled to a growing, locally regulated swarm cortex	Continuous, adaptive streaming intelligence
NYS	Learned oscillator coupling and thermodynamic phase dynamics	Associative, resonant conceptual exploration
AXIOM	Exact causal uncertainty, interventions, and reversible machine embodiment	Investigative machine scientist
Mech	Compiled knowledge graphs, explicit rules, retrieval, and deterministic proofs	Precise librarian-logician
EsoM	A self-enciphering .mal organism with native memory, search, and gated mutation	Persistent executable organism
WHIS	Quality-diversity evolution over populations, niches, and lineage	Discovery collective producing diverse strategies

These theses are durable. Their present implementations are not sacred.

A checkpoint, mechanism, trainer, representation, scale plan, or implementation branch may be disproved, archived, or replaced. A failed route is useful when its claim, controls, evidence, and failure are preserved. The program does not keep a route alive merely because it consumed substantial time or money.

Genesis hardware thesis

Genesis begins before hardware, compilers, runtimes, and models because it is trying to derive a compute model from first principles rather than inherit every CPU/GPU assumption.

Its discovery track proposes candidate computational phenomena. Its falsification track tries to eliminate artifacts, confounds, and false interpretations. Principles that survive may become software primitives, instructions, compiler/runtime semantics, RTL, FPGA implementations, and eventually physical hardware designed in KiCad.

The stated staged target is a non-CUDA compute architecture capable of running and training BulmaX through a host-CPU, reference-GPU, and Genesis-hardware system. The first proposed integration is deliberately narrow: validate exact persistent attention/KV-state behavior in software before FPGA offload. Other operations move only after Genesis earns the necessary arithmetic, memory, learning, and correctness primitives.

Genesis experiments are therefore neither side quests nor the final product. They are the evidence pipeline for deciding what deserves embodiment in a new physical compute substrate.

Non-negotiable product boundaries

1. The selected model owns the answer

A shared gateway may authenticate, route, enforce budgets, resolve permissions, and format envelopes. It may not secretly replace the selected model's cognition.

A model-specific parser or renderer may express a native result, but it must not invent the substantive reasoning that the named substrate did not perform.

2. Fallback is explicit

If one model cannot answer, it may abstain or request another named model. Automatic fallback is allowed only with prior user consent. Every response preserves both the requested model and the model that actually answered.

Another model's output must never be presented as though the selected model produced it.

3. Retrieval remains model-native

Repositories may share source storage, permissions, document identifiers, and provenance infrastructure. Each model must still ingest retrieved material in a form its own substrate can use and must own the inference that follows.

Retrieval finding the answer outside the substrate is not evidence that the model can reason about it.

4. Native state is isolated

Each model owns a separate state namespace, schema, reset rule, persistence rule, and rollback boundary. Neural memory, swarm topology, oscillator phase, causal quotients, fact graphs, .mal arenas, and evolutionary archives are not one interchangeable database.

Cross-model transfer is allowed only through an explicit, typed, consented, provenance-carrying artifact. It counts as learning only when the receiving model can ingest it into native state and a before/after evaluation demonstrates a useful, retained, reversible change.

5. Capability claims require native evidence

Code presence is not capability evidence. Checkpoint existence is not intelligence evidence. Lower loss is not automatically product progress. A bounded task does not establish open-domain generalization.

Consequential experiments should predeclare the claim, baseline, metric, minimum useful effect, resource ceiling, stop rule, artifact destination, and pass/fail decision. Evaluations default to native-only execution so fallback cannot conceal a failure.

6. State changes and actions are permissioned

Persistent learning, self-modification, tool use, experiments, hardware actions, and archive evolution require explicit permissions, resource ceilings, logs, and rollback where possible. Outside-user access must begin narrowly and honestly.

7. Backups and provenance are part of the architecture

Important source, checkpoints, experiment manifests, negative results, and lineage must be committed or stored in their declared durable home. A result that cannot be reconstructed from named revisions and artifacts should not guide an expensive next step.

Shared product direction

All seven models should eventually be reachable through one versioned request and response protocol, one model registry, and one outside-user-oriented chat surface. The shared membrane is infrastructure, not another intelligence.

The first protocol implementation lives in EsoM under src/model_family/ and is documented at:

https://github.com/dakuwonmoody-lab/EsoM/blob/main/docs/MODEL_PROTOCOL_V1.md

It requires explicit requested/answering model attribution, native evidence, state ownership, retrieval receipts, fallback receipts, resource budgets, and truthful availability. No adapter should be marked online until it has an exact runtime revision and passes conformance.

Compute direction

Progress is required across all seven model programs, but compute spending is not equal.

• CPU-appropriate architecture, evaluation, protocol, and product work continues even when accelerators are unavailable.
• Beerus and NYS use opportunistic accelerators only when a predeclared experiment justifies them.
• Full-current-configuration BulmaX work uses funded B200-class campaigns. BulmaX maintains a separate no-B200 queue for evaluation design, data audits, inference, serving, recovery, controls, and run preparation.
• Every expensive run begins with a decision-changing run card and ends with portable artifacts and frozen probes, not only a newer step number.
• Genesis hardware work proceeds only after software and reference-hardware gates establish correctness and value.

Repository responsibilities

Every participating repository owns its native architecture, local tests, evidence, state semantics, and failure history. Cross-repository product code must not erase those responsibilities.

Before substantial work begins, identify:

1. which model or Genesis thesis the work advances;
2. the exact current route under test;
3. the next falsifiable claim or native product rung;
4. the baseline or control;
5. the durable artifact destination; and
6. what result will cause continuation, revision, pause, or archival.

Meaningful progress includes a measured capability gain, a native end-to-end rung, a reliability improvement with evidence, a decisive ablation, or a negative result that eliminates a plausible route. Activity alone is not progress.

Immediate program priorities

• Shared product: turn protocol v1 into a thin gateway and seven conforming adapters with truthful availability.
• BulmaX: characterize the current checkpoint and make the next B200 campaign decisive.
• Beerus: freeze Swarm-Cortex as the canonical identity and prove the swarm adds value beyond the conv/GRU backbone.
• NYS: align sparse inference with the current sparse trainer and test ordered language plus phase ablations.
• AXIOM: finish A2 acceptance and the falsification/discovery campaign before broad language work.
• Mech: turn saved open-domain failures into regressions and win a curated domain through correctness, provenance, and calibrated unknowns.
• EsoM: resolve or redesign the re-entrant composition route while keeping answer-producing cognition inside .mal.
• WHIS: prove archive diversity improves a predeclared downstream consumer.
• Genesis: continue falsification-led principle discovery while protecting the staged bridge from software reference to FPGA and physical compute.

Canonical detailed documents

• Architecture and evidence audit: https://github.com/dakuwonmoody-lab/EsoM/blob/main/docs/MODEL_FAMILY_ARCHITECTURE.md
• One-year execution roadmap: https://github.com/dakuwonmoody-lab/EsoM/blob/main/docs/SEVEN_MODEL_EXECUTION_ROADMAP.md
• Shared protocol v1: https://github.com/dakuwonmoody-lab/EsoM/blob/main/docs/MODEL_PROTOCOL_V1.md
• Genesis hardware direction: https://github.com/dakuwonmoody-lab/genesis-computing/blob/main/README.md
• Genesis staged hybrid architecture: https://github.com/dakuwonmoody-lab/genesis-computing/blob/main/HYBRID_ARCHITECTURE.md

Repository-local specifications override the detailed implementation mechanics for their substrate. They do not silently override this cross-program product direction.

Synchronization rule

PROGRAM_CHARTER.md is mirrored at the root of every active source repository and relevant Hugging Face repository. Mirrors must remain byte-identical for a given charter version.

Changes begin in the canonical EsoM copy, increment the charter version, and are then synchronized across all mirrors in one documented operation. Do not make an independent repository-local edit to this file. Propose the change against the canonical copy and propagate it everywhere after acceptance.

If a mirror conflicts with the canonical copy at the same version, the canonical EsoM copy wins and the mismatch must be reported.