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.