Skip to content

Kernel + generated-views data model: the Lean gate is cleared #88

Description

@rsthornton

Context

The 6/09 architecture decision (K ≅ 2 is BERT's kernel; Klir/Bunge/Mobus are derived lenses) was gated on proving the view-derivations in Lean before touching the Rust data model. That gate cleared 2026-06-11: systems-science-foundations Systems/Klir/ViewGeneration.lean (commit abee84d, zero sorry).

What is now proven, and what it licenses here:

  • One kernel model + lens overlays is a theorem, not a bet. The kernel (things + dependency relation + the on-ness constraint) generates the Klir/Bunge/Mobus presentations as faithful views with identity round trips. Views never need separate storage; they are derived artifacts.
  • The preconditions are the validation rules. Generating a Bunge view requires the model to contain at least one bond between distinct components (HasBond); generating a Mobus view requires no self-dependencies (Irreflexive). These are machine-checked hypotheses — BERT's "view as X" affordances should gate on exactly these checks, and the error messages can say why (Bunge Def 1.1 / Mobus k ≠ o).
  • View-switching provably never mutates the model. Round trips are identities; switching lenses is read-only by theorem.
  • Slot count is a view property. The 8-tuple's slots are elaborations the Mobus view fills; the kernel stores none of them as primary data. "Why 8 not 7" is dissolved.

Scope

  • Sketch the Rust data-model mapping: kernel struct ↔ proven Kernel; view layer ↔ toKlir/toBunge/toMobus with their hypotheses as validators
  • Decide migration path for existing JSON models (kernel extraction = the proven projection direction)
  • UX unchanged by design: users draw entities/flows; the morphism stays hidden

Related: #75 (these lemmas are the composable blocks), #77 (the reference JSONs should be generated views, with the costs as their validation rules), #81 / gov-graphs#37 (cross-model inference sits on the shared kernel).


Spec: docs/system-language-spec-v2-addendum.md (committed 24ef433d on feature/bert-core — lands on main when that branch merges). Audit findings in the comment below.

Sequencing prerequisite: feature/bert-core is ~40 commits ahead of main (bert-core extraction + the compose thread + this spec), no PR open. Merge it before starting this refactor — building the kernel work on top of an unmerged 40-commit branch compounds the eventual integration.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions