Skip to content

feat: self-model, paper alignment notes, Mermaid architecture, marimo notebook#150

Merged
rororowyourboat merged 7 commits intomainfrom
dev
Mar 28, 2026
Merged

feat: self-model, paper alignment notes, Mermaid architecture, marimo notebook#150
rororowyourboat merged 7 commits intomainfrom
dev

Conversation

@rororowyourboat
Copy link
Copy Markdown
Collaborator

Summary

  • GDS self-model: ecosystem modeled using its own Component, DFD, and ERD diagram DSLs — 3 canonical forms (h=g, h=f.g, h=f)
  • Marimo notebook: interactive notebook rendering all three diagrams with Mermaid + canonical decomposition
  • Paper alignment notes: 5 disclaimers in formal-representability.md distinguishing paper-faithful claims from framework inventions
  • Mermaid architecture diagram: replaces ASCII tree on docs landing page
  • Research doc updates: Steps 3-5 marked DONE, StateMetric added to R1/R3 classification
  • gds-viz CI fix: test_phase.py skips when gds-continuous unavailable

Test plan

  • 8 ecosystem self-model tests pass
  • mkdocs build --strict passes
  • Ruff lint + format clean across all 462 files
  • Marimo notebook renders all 3 diagrams

rohan added 7 commits March 28, 2026 20:10
Mathematical audit against Zargham & Shorish (2022) via NotebookLM
identified 3 framework inventions vs paper definitions:

1. Composition algebra (Def 1.1): categorical structure is a framework
   design choice, not mandated by the paper's h(x) = f(x, g(x))
2. U_x decomposition (Property 4.5): paper defines U: X -> P(U) as a
   single map; struct/behav split is an ontological engineering choice
3. StateMetric split: paper's d_X is a single metric (Assumption 3.2);
   variable declarations (R1) vs distance callable (R3) is framework

Also noted: Rice's theorem R3 boundary applies to the implementation
scope (arbitrary Python callables), not the paper's mathematical scope
(compact/convex/continuous constraint sets per Assumption 3.5).

Canonical decomposition h = f ∘ g (Def 1.4) confirmed as faithful to
paper Definitions 2.6-2.9.
Dog-fooding: the GDS monorepo modeled as a component diagram using its
own gds-software package. 9 components (packages), 4 interfaces
(GDSSpec, SimAPI, ODEAPI, ControlAPI), 8 connectors.

Canonical result: h = g (stateless — pure API composition). Providers
(framework, sim, continuous) become BoundaryActions; consumers (DSLs,
analysis, symbolic) become Policies. No state, no mechanisms.

8 tests verifying compilation, canonical decomposition, verification,
and Mermaid output.
Three views of the GDS ecosystem modeled using its own DSLs:

Component diagram (prior commit): package dependencies as h = g
  (stateless API composition)

DFD pipeline: user workflow from spec→compile→verify→export→simulate→
  analyze as h = f ∘ g (full dynamical system with 4 data stores)

ERD data model: Pydantic model graph (GDSSpec→Block→Interface→Port,
  Entity→StateVariable→TypeDef, SpecWiring→Wire) as h = f
  (pure state, 9 relationships, 20 state variables)
@rororowyourboat rororowyourboat merged commit 3041c1d into main Mar 28, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant