Skip to content

Momir

13.7 Momir — Designer and Author

Responsibilities

  • consume Nissa's canonical diagnostic evidence directly;
  • consume the independently resolved GrowthRequest as operational constraints;
  • consume optional Sarpadian ancestry or retrieval context through a separate provenance-bearing channel;
  • design raw candidate graphs and birth parameters;
  • model a distribution over useful growths;
  • provide latent or mixture diversity;
  • reconstruct, mutate and recombine Sarpadian lineages during bootstrap;
  • generate ancestry-free candidates after scaffold withdrawal;
  • report generation uncertainty and measured spend;
  • and preserve provenance for every proposal.

Candidate modes

  • reference reconstruction during structural literacy;
  • deterministic direct design;
  • stochastic best-of-\(K\);
  • retrieved-parent mutation;
  • lineage recombination;
  • ancestry-optional or de novo generation;
  • conditional flow or diffusion only if simpler models fail;
  • or human-seeded design during research acquisition.

Invariants

  • Momir outputs raw proposals, not executable modules.
  • It cannot approve, test or deploy its own work.
  • It does not receive Narset hidden state, captions, diagnoses or topology hints.
  • Candidate count and orchestration metadata do not become covert semantic conditioning unless explicitly studied.
  • Candidate diversity is evaluated in canonical and functional space.
  • A generator version is bound to compatible telemetry, request and grammar versions.
  • Production inference remains valid with BootstrapAncestryContext = null.

Smell

If Momir is merely colouring in an answer Narset already wrote, the designer has become an executor. If Momir removes candidates because it dislikes their live test results, the author is grading its own examination.

Momir may learn from historical failures offline. It must not own the live admission boundary.