Forge Intelligence

Handbook

Forge Intelligence site and repository analysis for MathGenesis

Analysis date: 2026-07-22

Updated

Address resolution

The literal host supplied in the request, intelligence.forgesdl.com, was not reachable from the analysis environment. The authenticated source repositories identify the canonical custom domain as https://intelligence.forgesdlc.com and the Firebase site as forge-intelligence-handbook.

What the site actually is

The canonical site is the rendered handbook surface for the private forge-intelligence product. The writable source of truth is not the website:

  • autowww/forge-intelligence owns product Markdown, problem-class packs, registries, policies, LMeta units, FI-local LCDL contracts, artifacts, and session records;
  • autowww/forge-intelligence-website consumes the parent repository as a submodule, renders narrative Markdown through kitchensink/forge-autodoc, and deploys static HTML to Firebase Hosting;
  • the site generator intentionally skips runtime trees such as packs, lmeta, lcdl, schemas, sessions, and source code while publishing handbook-oriented Markdown.

Therefore, MathGenesis should generate repository-native, reviewable artifacts and let the existing handbook build publish selected narrative and wiki projections. It should not automate a browser form or mutate generated HTML.

Existing architecture that should be reused

Forge Intelligence already supplies a strong control plane:

  • general and specific problem-class intelligence;
  • packs/<domain>/policy.yaml with reasoning ladder, token caps, and closed allowed actions;
  • optional pack-level LMeta flows plus one LMeta unit per capability;
  • FI-local intelligence contracts while generic primitives remain in forge-lcdl;
  • typed artifact envelopes for all capability handoffs;
  • a router that can activate multiple intelligences and a DAG composer with dependencies, parallel groups, and fan-in gates;
  • maturity and allowlist gates with separate technical, autonomy, and evidence axes;
  • machine-canonical session records and generated human reports with a freeze gate;
  • paired LMeta semantic and LCDL execution wiki pages;
  • general intelligences for reasoning, creativity, concept invention, experimentation, system modeling/simulation, and validation/verification.

The existing general.concept-invention intelligence is directly reusable. Its nine capabilities already cover conceptual-gap detection, examples and counterexamples, essential characteristics, contrast sets, definition candidates, designation, ontology integration, operationalization, and concept evolution.

Existing knowledge-module surface

Current versioned knowledge modules live under:

knowledge/
  registry.yaml
  modules/

The current schema requires module_id, version, effective_from, and jurisdiction, with optional source snapshots, formulas, decision tables, examples, exceptions, and invalid-use cases.

That shape is useful for changing factual modules but is too shallow to represent a mathematical invention civilization. It does not natively distinguish:

  • primitive, axiom, definition, notation, theorem, proof, conjecture, counterexample, problem, solution, algorithm, representation, and invariant;
  • source attribution from formal proof, finite testing, numerical convergence, or empirical support;
  • exact prerequisite and dependency graphs;
  • geometric constructions, orientation, and degeneracy;
  • physical quantities, units, frames, initial/boundary conditions, approximation regimes, model-form uncertainty, and held-out evidence;
  • learner-visible seed knowledge from hidden modern-reference knowledge;
  • discovery staging, utility measurement, contamination audit, promotion, rejection, and historian comparison.

This pack therefore provides a compatibility wrapper and a recommended native schema/registry.

Runtime gap discovered during analysis

The current node executor is strong at envelope governance—input checking, fan-in, maturity gating, validator dispatch, artifact emission, and route tracing—but many LMeta units are still deterministic envelope emitters. Contract/runtime maturity does not by itself prove mathematical or physical correctness.

MathGenesis must add independent semantic validators and authenticated receipts before using strong statuses such as formally_verified, numerically_verified, or out_of_sample_validated.

Problem class Proposed intelligence Job
math/knowledge-ingest math.knowledge-curation Convert audited sources into typed library objects
math/problem-formalize math.problem-formalization Normalize symbols, assumptions, goals, and representations
math/proof-construct math.proof-engineering Build proof candidates and formal checker obligations
math/concept-mine math.concept-discovery Mine recurring structures from verified episodes
math/concept-promote math.library-governance Falsify, validate, deduplicate, measure, and govern promotion
geometry/solve-verify math.geometry Synthetic, construction, coordinate, and algebraic geometry
physics/model-test physics.model-discovery Unit-aware model construction, experiments, and regime validation
math/curriculum-evolve math.curriculum-evolution Generate near-frontier problems without solution leakage
math/historian-compare math.historian Post-freeze equivalence and bounded novelty assessment

Non-negotiable library partitions

  • reference — established modern knowledge; visible only to curators, validators, and the isolated historian.
  • learner_seed — minimal allowlisted primitives, axioms, constructions, and observation channels.
  • curriculum — learner-visible problems and world interfaces; solutions and target labels withheld.
  • discovery_staging — learner-generated candidates; untrusted by default.
  • promoted_discovery — candidates that passed independent validation, utility, ontology, contamination, and policy gates.
  • rejected — falsified, invalid, duplicate, overfit, contaminated, or evaluator-exploiting artifacts retained for learning.

No generation prompt should write directly to promoted_discovery. The promotion prompt emits a separate decision artifact, and ordinary governed repository tooling applies the accepted change.

  1. Add native schemas and validate the included examples.
  2. Use compatibility wrappers for the first reference batch.
  3. Add partition-scoped storage and retrieval before clean-room trials.
  4. Implement knowledge-ingest, geometry, physics, falsifier, and validation capabilities.
  5. Run Genesis-0 with a frozen learner snapshot and hidden historian target map.
  6. Add training-pair generation only from promoted or policy-eligible verified episodes.
  7. Publish handbook pages after semantic/execution wiki parity checks.