Skip to content

MATH-CORE-01 Council Deliberation 001

COUNCIL-MCORE-ARCH-001 — GCL mathematics architecture

Docket: MATH-PROGRAMME issue #721
Deliberation date: 2026-08-31
Protected baseline reviewed: grandchallenge/MATH-PROGRAMME@3c7aa5298debd6564e3f93a7a05b4f6821cd3bb2
Submitted memorial reviewed: records/MATH_CORE_01_GCL_MATHEMATICS_ARCHITECTURE_MEMORIAL.md at exact working commit 691f906b368adce389a0b0bfc94ff2c57f7d1d34
Authority state: Council recommendation only; Construction Gate registration, corrected-candidate Human Steward disposition, protected admission, and final documentary closure remain pending.

1. Purpose and review standard

The Human Steward approved the proposed MATH-CORE-centred GCL mathematics architecture as submitted and directed Council review for deliberation, potential amendments, approval, and memorialization. Council therefore reviews the architecture without treating the initial approval as advance approval of any material correction.

Standing governance requires the fifteen Agent Council offices: Axiomatist, Prospector, Experimentalist, Cartographer, Verifier, Adversary, Formalist, Steward, Composer, Grammarian, Amanuensis, Archivist, Mechanist, Typesetter, and Referee. As in the earlier CMDG ratification proceeding, this docket uses the stronger operational quorum rule that all fifteen offices must record a finding and the Referee must synthesize the record before a Council recommendation is presented to the Human Steward. This docket-specific rule does not amend standing governance.

Council reviewed the submitted memorial together with MATH_CORE_01_CLAIM_BLACKBOARD_PROTOCOL.md, ARCHITECTURE_OVERVIEW.md, AGENTS.md, the Agent Council governance/checklist, Claim Ledger and certification contracts, current Construction Gate policy, current mandatory execution-routing policy, the UC-001 MATH-CORE pilot, and the protected Condensed Mathematics CM1-CM4 workflow/evidence spine.

2. Office deliberations

2.1 Axiomatist

Disposition: RATIFY_WITH_CORRECTIONS

The separation among governance, reasoning-state semantics, exploratory reasoning, independent assurance, and canonical acceptance is sound. The architecture correctly refuses to equate a state transition with a proof or a Human Steward disposition with mathematical evidence.

Axiomatist requires the trust/authority vocabulary to distinguish: proof-checking substrate; independently checked evidence; canonical governed claim state; and policy authority. The canonical Claim Ledger is a governed state surface, not a proof kernel. MATHCERT is an assurance institution, not the foundational kernel itself. These distinctions should be explicit in the controlled architecture vocabulary.

2.2 Prospector

Disposition: RATIFY

The architecture has strong strategic leverage because it permits many research programmes to share stable institutions without turning every new capability or domain into a new pillar. Representing domain programmes as long-lived MATH-CORE subgraphs is preferable to repository-driven ontology.

Condensed Mathematics is the correct first substantial application after UC-001 because its protected dependency spine and open frontier are already sufficiently structured to test the model without inventing a synthetic programme.

2.3 Experimentalist

Disposition: RATIFY_WITH_CORRECTIONS

Before a live coordinator is trusted with sustained research allocation, the architecture needs retained end-to-end fixtures for stale checkpoints, concurrent proposals, supersession/invalidation, replayable conflicts, cross-domain bridge attempts, and attempted status inflation during legacy migration.

The first Condensed integration should be a read-mostly shadow materialization: construct the MATH-CORE graph from existing protected CMDG/CM artifacts and compare it with current validators before allowing the graph to drive allocation or pruning.

2.4 Cartographer

Disposition: RATIFY_WITH_CORRECTIONS

The plane/pillar/programme distinction is structurally sound, but the submitted memorial creates one role drift against protected ARCHITECTURE_OVERVIEW.md: MATHFORGE is described too narrowly as source/formal-object production. Standing doctrine defines it more broadly as the discovery/source foundry, including source intake, examples, computational exploration, and speculative candidates. MATHSOLVE remains the disciplined campaign/obligation attack layer.

Domain programmes should be scoped subgraphs with explicit programme/family identity. Cross-domain edges must be typed bridge relations; equivalence or evidence in one domain must not silently propagate authority into another domain.

2.5 Verifier

Disposition: RATIFY_WITH_CORRECTIONS

The architecture is independently checkable in principle, but production conflict-driven pruning requires stronger evidence binding than protocol v0.1 currently demands. REPLAYABLE evidence should be anchored to an exact checkpoint and content-addressed artifact, content set, or versioned replay manifest. Strong witness classes should likewise carry exact artifact identity where relied upon for resolution or pruning.

Before live coordination, the acceptance path should emit deterministic acceptance/rejection receipts for proposed events so that replay can distinguish agent proposal from reducer admission.

2.6 Adversary

Disposition: RATIFY_WITH_CORRECTIONS

Adversary tested the model against authority laundering and stale-state attacks. Required retained attacks include:

  • producer-class spoofing without authenticated execution identity;
  • stale-response acceptance after the blackboard tip changes;
  • conflict-assurance inflation;
  • witness-to-theorem laundering;
  • cross-domain equivalence laundering;
  • historical-state backfill represented as if it were contemporaneous live reasoning;
  • superseded evidence remaining active after a dependency changes;
  • certificate existence being treated as direct ledger promotion;
  • bounded conversational execution being mistaken for an unattended persistent controller.

No attack requires rejection, but these must become implementation gates before live autonomous coordination.

2.7 Formalist

Disposition: RATIFY_WITH_CORRECTIONS

The Condensed placement is faithful only if formal replay status is kept separate from theorem/canonical status. CM1-CM3 currently provide protected replayed formal evidence and dependency-validation layers; MATH-CORE import must preserve their exact existing semantics rather than re-describe every protected fixture as a new certified theorem.

The architecture should continue to permit programme-specific semantic validators above generic MATH-CORE validity, as UC-001 already demonstrates. Formal validity of an event envelope is not sufficient evidence that a domain-specific obligation is discharged.

2.8 Steward

Disposition: RATIFY

The reader contract is strong if the public description stays simple: MATH-CORE is the shared reasoning-state substrate; INTELLECT decides where to work; the pillars perform specialized work; trusted mechanisms and governance decide what is accepted.

The term trusted acceptance plane should not be explained as one monolithic authority. Public documentation should state that proof checking, independent assurance, canonical recording, and policy disposition are separate functions even though they sit below the live-reasoning boundary.

2.9 Composer

Disposition: RATIFY_WITH_CORRECTIONS

The architecture should be memorialized in layers rather than by allowing the present candidate memorial to become a mutable omnibus specification. After ratification:

  • the memorial remains the rationale/reference;
  • ARCHITECTURE_OVERVIEW.md carries the concise normative topology;
  • MATH-CORE schemas/protocol carry machine semantics;
  • domain integration specifications carry migration detail;
  • the ADR records the ratified decision and corrections.

This separation is required to keep later implementation changes from rewriting the historical rationale.

2.10 Grammarian

Disposition: RATIFY_WITH_CORRECTIONS

Council requires controlled definitions for at least: plane, pillar, domain programme, theory agent/service, transport fabric, trusted acceptance boundary, canonical state, protected dependency layer, and the blocker classes used by domain programmes.

Stable pillar must not mean immutable pillar. New capabilities should default to services, but creation, retirement, or redefinition of a pillar remains possible through explicit governance.

2.11 Amanuensis

Disposition: RATIFY_WITH_CORRECTIONS

The architecture is not yet durably authoritative. The docket is mutable; the memorial is on an ordinary working branch; the Construction Gate target is not yet protected. Final memorialization must preserve the submitted memorial, this deliberation, machine-readable review, exact corrected candidate, Human Steward disposition, ADR, decision index, artifact ledger, terminology changes, architecture reconciliation, exact-head policy evidence, independent review, protected merge, protected-main readback, and terminal documentary closure where applicable.

No Council recommendation should be described as protected authority before that chain is complete.

2.12 Archivist

Disposition: RATIFY_WITH_CORRECTIONS

Migration must be additive and provenance-sensitive. Existing campaigns were not historically generated by MATH-CORE and must not be rewritten as though they were. Imported protected state should be labeled as reconstructed/imported state with exact source identities, while new live events begin only from the declared migration checkpoint.

Historical programme names and repository roles should be preserved in provenance even if the architecture gives them a new common representation.

2.13 Mechanist

Disposition: RATIFY_WITH_CORRECTIONS

The submitted architecture must be reconciled with the newly protected mandatory execution-routing contract. A bounded conversational agent may perform authorized transactions, but it may not be the sole persistent controller for unattended INTELLECT campaigns. Any persistent live coordinator must run under an exact admitted controller with compatible capabilities.

Before live INTELLECT operation, the implementation contract should also provide authenticated producer identity external to the declared producer class, optimistic/exact-checkpoint concurrency control, stale-result rejection, supersession/invalidation rules, bounded resource budgets, and deterministic admission receipts.

2.14 Typesetter

Disposition: RATIFY

The architecture is visually and documentarily tractable. The preferred canonical diagram should show planes as horizontal bands, pillars as stable vertical/service institutions, domain programmes as scoped graphs within MATH-CORE, and AETHER as orthogonal infrastructure. It should not draw domain programmes as a software layer through which all pillar calls literally pass.

Condensed Mathematics should be displayed as one populated domain graph rather than as a fourth pillar.

2.15 Referee

Disposition: RATIFY_WITH_CORRECTIONS

Quorum is achieved: 15/15 required offices reviewed; all fifteen support adoption; there is no RETURN_FOR_REVISION or REJECT position.

The architecture is coherent and materially improves the Programme's separation of concerns. Eight corrections are required before protected architectural authority should activate. They refine role continuity, terminology, domain isolation, live-coordinator safety, assurance binding, Condensed migration, execution routing, and documentary closure. None changes a mathematical claim or certificate.

The corrected candidate must return to the Human Steward for explicit exact-candidate ratification because the initial Human Steward approval predates these amendments.

3. Council correction register

MCORE-ARCH-C01 — Preserve and reconcile the three-pillar doctrine

MATHFORGE remains the broader discovery/source foundry described by protected ARCHITECTURE_OVERVIEW.md; it is not reduced to source-integrity/formal-object work. MATHSOLVE owns disciplined campaign reasoning against explicit obligations. MATHCERT remains independent assurance. The corrected memorial and later architecture overview must reconcile this boundary explicitly.

Owner: Cartographer / Composer
Stage: before protected architectural admission
Blocking: yes

MCORE-ARCH-C02 — Install controlled topology and authority vocabulary

Define plane, pillar, domain programme, theory agent/service, transport fabric, trusted acceptance boundary, canonical state, and protected dependency layer. Clarify that stable pillars are governed institutions, not immutable ontology; new pillars require explicit governance. Separate proof-checking substrate, independent assurance, canonical recording, and policy disposition.

Owner: Grammarian / Axiomatist
Stage: before final authority-surface integration
Blocking: yes

MCORE-ARCH-C03 — Define domain-subgraph isolation and bridge semantics

Every domain graph must carry explicit scope identity and migration checkpoint. Cross-domain dependencies/equivalences must be typed bridges with explicit evidence and may not transfer certification or canonical status implicitly.

Owner: Cartographer / Adversary
Stage: before multi-domain live coordination
Blocking: yes for multi-domain operation; nonblocking for architecture ratification once recorded

MCORE-ARCH-C04 — Harden live coordinator identity, concurrency, and invalidation

Before live INTELLECT coordination, require authenticated producer/execution identity outside the self-declared producer class; exact-checkpoint concurrency and stale-response rejection; deterministic admission receipts; supersession/invalidation semantics; bounded request budgets; and explicit prohibition on self-authorization.

Owner: Mechanist / Verifier / Adversary
Stage: before live coordinator deployment
Blocking: yes for live coordination; nonblocking for architecture ratification once recorded

MCORE-ARCH-C05 — Bind replayable assurance to exact evidence

Before production REPLAYABLE/CHECKED conflict-driven pruning, bind replay evidence to an exact checkpoint and content-addressed artifact, content set, or versioned replay manifest. Establish exact artifact-identity requirements for witness classes used to resolve or prune obligations.

Owner: Verifier / Formalist
Stage: before production conflict-driven pruning
Blocking: yes for that capability

MCORE-ARCH-C06 — Govern Condensed migration and blocker taxonomy

Import CM1-CM3 and other protected historical state as provenance-bound external/protected references, not retroactive live MATH-CORE history. Preserve distinctions among formal replay, protected dependency status, canonical claim status, and certification. Classify active blockers at least as MATHEMATICAL, FORMALIZATION, GOVERNANCE_EVIDENCE, and EXECUTION_INFRASTRUCTURE; the fourth class prevents runtime/tooling failures from being mislabeled as formal mathematics blockers.

Owner: Formalist / Archivist / Experimentalist
Stage: before first Condensed shadow materialization is promoted beyond observation
Blocking: yes for Condensed integration

MCORE-ARCH-C07 — Bind persistent coordination to mandatory execution routing

AETHER remains authority-neutral transport/memory. Any unattended persistent INTELLECT/MATH-CORE controller must use an exact admitted persistent controller with compatible capabilities under current GHOS routing policy. A bounded conversational agent may execute individual authorized transactions but may not be represented as the sole persistent controller for unattended campaigns.

Owner: Mechanist
Stage: immediate standing constraint
Blocking: yes for unattended operation

MCORE-ARCH-C08 — Complete governed memorialization and terminal documentary closure

Preserve the memorial, Council deliberation, machine review, corrected exact candidate, Human Steward disposition, ADR, decision index, artifact ledger, terminology registry, architecture reconciliation, exact-head CI, independent review, protected merge, protected-main readback, and applicable documentary closure/readback seal. Do not describe the architecture as protected/canonical before these authority surfaces agree.

Owner: Amanuensis
Stage: before protected authority activation
Blocking: yes

Council recommends MCORE-DOMAIN-SHADOW-001 as the first post-ratification operation: a read-only Condensed Mathematics shadow materialization that imports the protected CM1-CM4/CMDG dependency state into a MATH-CORE domain graph, preserves exact provenance and status distinctions, introduces no retroactive live-event fiction, drives no pruning or autonomous allocation, and is compared against existing protected validators.

Only after C03-C07 are discharged at their applicable gates should INTELLECT use the materialized graph to allocate or prune live research work.

5. Council disposition

Council disposition: RATIFY_WITH_CORRECTIONS

  • Offices reviewed: 15/15
  • Support adoption: 15/15
  • RETURN_FOR_REVISION: 0
  • REJECT: 0
  • Blocking corrections before protected architectural authority: C01, C02, C08
  • Stage-bounded implementation gates: C03-C07

The Council recommendation does not itself activate protected authority. The corrected exact candidate must be produced, checked for faithful integration of C01-C08, and returned to the Human Steward for explicit disposition.

6. Claim boundary

Council ratification of this architecture would authorize an organizational and technical integration model only. It does not prove or certify new mathematics, upgrade any Condensed frontier theorem, certify a dependency edge merely because it is represented, establish foundational consistency, create novelty or priority, or authorize publication, patentability, product, deployment, or commercial claims.