{"id":51379195,"url":"https://github.com/moqui/moqui-math","last_synced_at":"2026-07-03T15:10:05.828Z","repository":{"id":366197242,"uuid":"1237993333","full_name":"moqui/moqui-math","owner":"moqui","description":null,"archived":false,"fork":false,"pushed_at":"2026-06-03T08:28:37.000Z","size":78,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-06-20T18:27:55.619Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/moqui.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.md","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":"AUTHORS","dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-05-13T17:54:01.000Z","updated_at":"2026-06-09T21:39:51.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/moqui/moqui-math","commit_stats":null,"previous_names":["moqui/moqui-math"],"tags_count":null,"template":false,"template_full_name":null,"purl":"pkg:github/moqui/moqui-math","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/moqui%2Fmoqui-math","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/moqui%2Fmoqui-math/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/moqui%2Fmoqui-math/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/moqui%2Fmoqui-math/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/moqui","download_url":"https://codeload.github.com/moqui/moqui-math/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/moqui%2Fmoqui-math/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":35090622,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-07-03T02:00:05.635Z","response_time":110,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-07-03T15:10:04.603Z","updated_at":"2026-07-03T15:10:05.800Z","avatar_url":"https://github.com/moqui.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Moqui Math\n\n[![license](http://img.shields.io/badge/license-CC0%201.0%20Universal-blue.svg)](https://github.com/moqui/moqui-math/blob/master/LICENSE.md)\n\n**PLM for mathematical models: the model is the product, with a lifecycle, a change history, and proof.**\n\nWhen AI reshapes a model on the fly — a network topology, a simulation's mesh, a\ncontroller's law — that change is a decision that should be frozen and validated\n*before* it becomes real. Today it lands in a data lake, or at best in a workflow\naudit log that records the *action* but not the *model*. This is the structured\nspace for the model itself.\n\n**A structured space for mathematical models, their evolution, and the proof that they do what they claim — not a data lake.**\n\nMoqui Math is a Moqui Framework component: a relational data model for applied\nmathematics, with no runtime code and no external dependencies. It covers the\nstructures used in industrial automation, scientific computing, and\nmachine-learning pipelines.\n\nBut the entity catalogue is not the point. This is.\n\n## Why this exists\n\nToday a mathematical model that *acts on the physical world* — a trajectory\nplanner driving a robot arm, a controller setpoint, a PINN learning a\nthermodynamic process, a CFD field validated against a wind tunnel — leaves\nalmost no governable trace of **what it was, why it changed, and on what proof\nit was allowed to run.**\n\nThe numbers end up in one of two bad places:\n\n- a **data lake**: unstructured blobs you hope to make sense of *later*, with AI\n  generating them faster than anyone can keep up — semantics reconstructed\n  after the fact, if ever; or\n- an **MLOps registry**: it versions the artefact (the weights, the file) but\n  knows nothing about the physical device that executes it, the specification it\n  is supposed to approximate, or the evidence that it stays within tolerance.\n\nNeither records the *fact*. Both leave you, ten years later, holding numbers\nnobody can explain.\n\nAnd \"ten years\" is not rhetorical. Under the **EU AI Act** (Reg. 2024/1689),\nproviders of high-risk AI systems must keep technical documentation and\nautomatically generated logs for **ten years**, demonstrating — with verifiable\nevidence, not description — that the system meets its requirements throughout its\nlifecycle. Industrial machinery, medical, and other regulated domains carry\nparallel obligations. A data lake cannot produce that evidence on demand; an\nartefact registry does not know the device or the specification. What the\nregulation asks for is precisely a *governed fact with proof attached* — which is\nwhat this model is built to hold.\n\n## What it does instead\n\nMoqui Math treats a model the way accounting treats a transaction.\n\nIn a warehouse you can record every stock movement, one event at a time, when\nyou need full traceability — or post a daily or monthly aggregate when you don't.\nEither way you record the **movement that changes the ledger**, never the\nintermediate arithmetic of a line total. Thermodynamics and motion are no\ndifferent: there is always an event that *changes the system*, and that is the\nthing worth keeping.\n\nA data lake refuses this discipline. It keeps everything, unstructured, and\ndefers meaning forever — and with AI now writing into it faster than any human\ncan audit, \"later\" never comes. You are left with petabytes no one can read.\nA workflow audit log is the opposite failure: it faithfully records *that* an\nagent acted — invocation, tool call, rollback — but not the *model* the action\nproduced, in typed and validatable form. This model is a third stance: not \"save\neverything\" (you drown), not \"log only the action\" (you keep the gesture, lose\nthe object), but **save the fact, structured at the moment of writing**, so its\nmeaning is known *a priori* and never has to be reconstructed.\n\nYou don't journal every intermediate multiplication — you journal the **event\nthat changes the system** and carries consequences. A rotation matrix recomputed\nidentically every cycle is a calculation; the moment a model *redefines the\ndynamics that govern what happens next* is a fact, and a fact deserves an entry:\nwho, when, from what state to what state, on what evidence.\n\nAnd the fact is not only the running model. It is the **whole lifecycle of the\nmodel as a product**: its conception, its prototype, each revision of its\ndiscretization or formulation, and the **change management between releases** —\nwhere a human approval gate, and where required the legal or compliance\ndepartment, can sit *between one version and the next* before a model is allowed\ninto production. The AI Act forbids a system from promoting itself into\nproduction without oversight; here that gate is a native, dated, signed\ntransition, not an afterthought.\n\nThe component supplies the **structured space** for all of this. It does not\ndecide for you which events are salient — that judgement belongs to the domain\nexpert (the process engineer, the physicist, the field technician). A colour\nshift on a curing salami may be exactly the event one producer records, because\nit links colour to water activity to a prediction of how the curing will go;\nanother producer ignores it. The schema does not need to know in advance. It\nguarantees only this: **whatever you choose to record is born with known\nsemantics, instead of having to be reverse-engineered from a blob.**\n\nGranularity is yours: event-by-event when you need fine traceability, aggregated\nwhen you don't. The schema imposes meaning, not frequency.\n\n## The Math–Device duality\n\n`moqui.math` and `moqui.device` are two faces of one problem. **You cannot run a\nmodel without a device** (CPU, GPU, PLC, edge accelerator); **you cannot\nmeaningfully describe a device without modelling what it computes.**\n\nThe binding entity `DeviceMathModel` (in `moqui-device`) connects the two sides,\nso the *same* governance machinery — config history, rule evaluation, audit log,\neffective dating — serves a PLC moving a servo and a GPU cluster training a\ntransformer, unchanged. The only knob that differs is the device type.\n\nThis is the part no MLOps tool has, because they all come from the software side\nand treat the device as a deployment detail. Here it is co-primary.\n\n## Specification, realization, and proof\n\nThe pairing that makes this a *lifecycle* system, not just a registry:\n\n- a **`Transformation`** is the specification — what the model is meant to do;\n- an **`ApproximatedFunction`** / `MathModel` is the realization — the network,\n  the fit, the controller that actually does it;\n- a **`MathModelRun`** produces the evidence — metrics, and the measured error\n  of the realization against the specification.\n\nA neural trajectory planner can be bound to the classical planner it\napproximates, with its maximum relative error recorded as a dated, versioned\nproof of conformance. This is the structure regulated domains need: not a\ndescription of the model, but **verifiable evidence that it does what it must,\nwithin a declared tolerance** — retainable, auditable, intelligible years later.\n\nFor outputs that are *not* explainable (an opaque network), the schema records\nexactly that. \"Explainable / not explainable\" becomes a tracked attribute with\nconsequences, rather than a false post-hoc rationalization.\n\n## Graphs and meshes are not minor state\n\nIt is tempting to read `Graph` and `Mesh` as bookkeeping — secondary tables\nhanging off the real model. They are the opposite. A graph topology and a mesh\ndiscretization *are the decision*: the exact thing an AI will increasingly change\n**at runtime, on your behalf**, reshaping the model while it runs.\n\nConsider an SDN network controller. An AI decides, on the fly, how to rewire the\nrouting graph between routers — adding a path, isolating a node, changing the\ntopology to absorb a failure or a traffic surge. That new graph is not telemetry.\nIt is a control decision with consequences, made faster than any operator could\nreview it. Agent-driven network operations already log *that* the agent acted,\nwith audit and rollback — but the *candidate graph itself*, frozen and validated\nagainst constraints **before** it goes live (exactly what a network digital twin\nneeds to simulate the next state before deployment), is a typed model object, not\na workflow event. *Who changed the topology, when, from what graph to what graph,\non what evidence, and under whose authority* is the fact that must survive — the\nsame way a remesh that changes a simulation's discretization, or a model that\nre-selects its own structure mid-run, is a decision and not a side effect.\n\nWhen the AI changes the graph or the mesh, it is changing the model. This is\nwhere that change becomes a recorded, governable fact instead of an unexplained\nreconfiguration.\n\n## Why it is the future of Model Lifecycle Management\n\nWith PID control, a historian was enough. With learned models — PINNs, neural\nplanners that adapt to real evolution — the model itself becomes an object with\nstate, versions, and proof obligations. It stops being a log line and starts\nbeing a transaction.\n\nMLM today is artefact versioning. What's missing — and what this provides — is\nthe model as a **governed fact**, joined to the physical device that runs it and\nto the evidence that licenses it to run. That space does not exist elsewhere.\nMoqui Math is built on a stable, sedimented universal data model (Silverston via\nOFBiz/Moqui), so its stability comes from the structure it attaches to, not from\nthe churn of any release cycle.\n\nIt records the fact, and only the fact. Not everything (you drown), not nothing\n(the blob you rightly distrust) — the structured space in between.\n\n---\n\n## Contents\n\n| Domain | Entities |\n|---|---|\n| Parameters / Variables | `ParameterDef`, `Parameter`, `ParameterLog` |\n| Linear Algebra | `Vector`, `VectorComponent`, `Matrix`, `MatrixComponent` |\n| Tensors | `Tensor`, `TensorAxis`, `TensorElement`, `TensorContent` |\n| Tensor operations | `MatrixDecomposition`, `TensorDecomposition`, `TensorDecompositionFactor`, slices, extractions |\n| Coordinate Systems | `CoordinateSystem`, `CoordinateSystemBaseVector`, `CoordinateSystemMetric`, `CoordinateSystemTransformation` |\n| Transformations | `Transformation`, `TransformationOperand`, `DiagonalExtraction`, `TriangularExtraction`, `BandExtraction`, `BlockMatrixExtraction`, `NormResult` |\n| Approximated Functions | `ApproximatedFunction`, `ApproximatedFunctionSample`, `ApproximatedFunctionDerivative` |\n| Mathematical Models | `MathModelDef`, `MathModelDefIdentification`, `MathModelDefContent`, `MathModel`, `MathModelRun`, `MathModelEvent`, `MathModelPerf`, `MathModelData` |\n| Graph Theory | `Graph`, `GraphVertex`, `GraphEdge`, `GraphContent` |\n| Finite-Element Mesh | `Mesh`, `MeshContent`, `MeshQuality`, `MeshKCell`, `MeshKCellVertex`, `MeshKCellEdge`, `MeshKCellIncidence`, `MeshGroup`, `MeshGroupMember` |\n| Trajectories | `ParametricPath`, `ParametricPathPoint`, `ParametricPathContent`, `ParametricPathEvent`, `Trajectory`, `TrajectoryPoint`, `TrajectoryPointRun`, `TrajectoryRun`, `TrajectoryStats` |\n| Category Theory | `Category`, `CategoryObject`, `Morphism`, `MorphismComposition`, `Functor`, `FunctorObjectMapping`, `FunctorMorphismMapping`, `NaturalTransformation`, `NaturalTransformationComponent`, `NaturalTransformationComposition` |\n\n### Tensor storage\n\nThe `Tensor` entity keeps the **semantics** (axes with purpose and unit of\nmeasure, coordinate system, lineage, proof) in the relational model and the\n**bytes** in a backend chosen via `storageTypeEnumId` and `TensorContent`:\nrow-per-element, JSON/BLOB array fields, or external files (NumPy `.npy`, Zarr,\nSafetensors, Apache Arrow IPC, HDF5, Parquet, TileDB, PyTorch `.pt`). Sparse\nformats include COO, CSR, CSC, BSR, BSC. The opaque payload stays out; the\nmeaning stays in.\n\n### Mathematical Models\n\n`MathModelDef` carries the PLM lifecycle (Draft → Approved → Production →\nRetired) and external-registry identification (Hugging Face ID, OpenAI model\nname, MLflow registered model ID, etc.). `MathModel` is a concrete instance;\n`MathModelRun` tracks training, eval, or inference runs with status flows,\nmetrics, and events.\n\n## Dependencies\n\nNone.\n\n## Install\n\n    ./gradlew getComponent -Pcomponent=moqui-math\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmoqui%2Fmoqui-math","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmoqui%2Fmoqui-math","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmoqui%2Fmoqui-math/lists"}